Solutions · Repository connectors

GCdocs for ATIP: OPI records straight onto the request

For Access to Information Act and Privacy Act requests, AccessPoint brings your department's GCdocs into the request itself. ATIP analysts — and the OPI staff you allow — search GCdocs and add records as themselves once your department grants AccessPoint OTDS impersonation, so GCdocs permissions decide what each person sees, and every record arrives with its GCdocs location, version and a verified SHA-256 hash.

A federal access request starts a 30-day clock on the day it is received, and the records that answer it are seldom held by the ATIP office. GCdocs is the Government of Canada's standard electronic document and records management solution, used by more than 70 federal organizations, so the search becomes a tasking: the offices of primary interest that own the GCdocs workspaces look for records, download what they find and send it back by e-mail or through a shared folder. The analyst ends up with copies that have no GCdocs location and no version, the clock keeps running while they trickle in, and when the Information Commissioner later asks how the institution searched, the answer is scattered across inboxes.

GCdocs runs on OpenText Content Server, so AccessPoint reaches it through its OpenText Content Server connector, set up for your department's own GCdocs instance: its address, its OTDS partition and the workspaces you choose to offer. A GCdocs tile then appears in the Add from… picker on every ATIA and Privacy Act request, beside SharePoint, Outlook and Teams. Analysts browse GCdocs folders, search by name, date, location or full text, and add records; an OPI tasked on the request can do the same from its own assignment, against the GCdocs folders it named. Each record is copied into the request server-side and goes through the same processing as an upload — PDF conversion, search indexing and the redaction pattern scans — so it is ready for review as soon as it lands. The connector page covers the API, the search syntaxes and the metadata in technical depth.

Each department's GCdocs is its own Content Server and OpenText Directory Services (OTDS) instance, with its own address, partition and administrators, and API access to it is a departmental request rather than self-service. Through your IT service desk or the GCdocs service desk, departmental IM/IT asks for an OTDS client allowed to act for AccessPoint's users, a read-only service account and network reach from the connector's host. With that grant in place, every search and capture runs as the analyst or OPI who made it: GCdocs applies the permissions the department has already set, and its own audit trail names the person rather than a shared ATIP account. Until the grant arrives, the connector can run on a single read-only service account, with AccessPoint's case permissions as the per-person gate.

Expect a GCdocs front end to be reachable only from the GC network. The connector therefore runs on a departmental host beside GCdocs, as a Windows service or a Linux container, and Microsoft's Hybrid Connection Manager on the same host makes an outbound connection to an Azure Relay in your subscription — no VPN and no inbound firewall rule. GCdocs holds information up to Protected B. The connector keeps no document bytes, and captured records are stored only in the request's storage in your own Azure subscription; confirm with your departmental security authority that your AccessPoint deployment's own assessment covers the records you capture, starting from the GC security controls reference. OpenText is a trademark of Open Text Corporation, and GCdocs is a Government of Canada service operated by Shared Services Canada; AccessPoint is not affiliated with or endorsed by OpenText or the Government of Canada.

Sound familiar?

Three moments every ATIP office that depends on GCdocs will recognize.

The OPI's zip file

An office of primary interest finds forty responsive documents in GCdocs, downloads them, zips them and e-mails the file to ATIP. The analyst opens copies with no GCdocs location, no version number and nothing to show they match what GCdocs held on the day of the search.

Day 22, and the retrieval is still out

The tasking went to three OPIs on day two. One answered, one sent a GCdocs link the analyst can't open, and one is waiting on a colleague who is back next week. The 30-day clock doesn't wait, and the only record of who has sent what is the analyst's sent folder.

The complaint about the search

A requester tells the Information Commissioner that records are missing. The investigator asks which GCdocs folders were searched, with what terms, by whom and when — and the answer is a chain of e-mails, one of them from an employee who has since moved to another department.

What to ask of any tool that reaches into GCdocs for ATIP

Whatever you choose — including if it isn't AccessPoint — put these questions to it before it touches your department's GCdocs.

The department's permissions, per person Each analyst and OPI should see only what their own GCdocs permissions allow, enforced by GCdocs through OTDS — not whatever a broad ATIP account can reach.
A clear request for the GCdocs service desk API access is a departmental approval. The vendor should tell you exactly what to ask for — the OTDS client, the impersonation grant, a service account and network reach — and keep working in a fallback mode while it is pending.
Runs inside the GC network The connector should sit on a departmental host beside GCdocs and connect outward, with no inbound firewall rule and no VPN to the cloud.
Protected B stays in your tenant Records should move from GCdocs to storage in your own Azure subscription and nowhere else — no vendor cloud in between, and no document bytes kept at the connector.
OPIs collect into their own tasking An OPI should be able to search the GCdocs folders it named on its assignment, add what it finds and attest to the search — without ever seeing who made the request.
A search you can show the Commissioner Who searched, where, when, and exactly which version of each record was taken should be recorded as the work happens, not rebuilt from e-mail afterwards.

How GCdocs fits the ATIP workflow

From the OPI's tasking to the analyst's review, GCdocs records stay attached to the request they answer.

A GCdocs tile on every request

Analysts open Add from… on an ATIA or Privacy Act request and choose GCdocs beside Microsoft 365. Browse from the workspaces your department offers — the Enterprise Workspace, a records centre, a departmental workspace — or search by name, date, location or full text.

OPI tasking bound to GCdocs folders

On a custodian assignment, a repository row can be bound to a GCdocs folder. Browse here and Search here open GCdocs at that place, records taken from there count against the row, and Records found is suggested — the OPI's own statement still stands.

Each person's own GCdocs

With the OTDS grant, GCdocs trims every listing and search for the person asking, and AccessPoint checks access again just before each capture. A record that person may not open is skipped as access denied.

Suggestions from the request's own words

The Suggested documents tab asks GCdocs for records matching the request's terms and period. Ask AccessPoint can list the GCdocs hits you may see — names, paths and dates only — and captures nothing until you confirm.

A whole workspace in one job

Collect this folder… takes an OPI's folder tree in the background, filtered by modified date, name pattern or extension and mirrored into the request's folders — and a re-run skips what is already there.

The requester stays anonymous to OPIs

OPI staff work behind AccessPoint's PII filter, enforced server-side, so tasking them with a GCdocs search never shows them who asked.

The record of the search

When the Information Commissioner asks how you searched GCdocs

The Information Commissioner's guidance looks for a search in which "one or more experienced employees, knowledgeable in the subject matter of the request, must have made reasonable efforts to identify and locate all records reasonably related to the request" — and the way to show that is a record made while the search happened. In AccessPoint, every GCdocs record on a request keeps its Source details: the GCdocs path and node id, the version taken, the SHA-256 hash with a Verified, Mismatch or Not declared pill, who captured it and when, the repository row it was collected for and the job it arrived through. Each OPI's attestation closes its assignment, the request's audit ledger records every capture, and with the OTDS grant the GCdocs audit trail names the person who opened each record.

Who, where and when Each capture is on the ledger with its connector, item, version, hash and purpose.
The copy GCdocs held A frozen copy with a verified hash, never a live link that can change under the request.
Provenance that travels Source path, item id, version, hash and capture date go with a tenant export.

From GCdocs to the ATIP file

What a department does to bring its GCdocs into AccessPoint:

  1. Raise a request with your IT service desk or the GCdocs service desk for an OTDS OAuth client with the token-exchange grant (or a service account with impersonation allowed), a read-only service account for health checks, and network reach from a departmental host to GCdocs and OTDS.
  2. Have departmental IM/IT register the AccessPoint Connectors app in Microsoft Entra ID and deploy the connector on that host, pointed at your GCdocs instance, with the workspaces you want to offer and its secrets kept out of the configuration file.
  3. Have your AccessPoint administrator create a Hybrid Connection for the connector's host name and port, then install Microsoft's Hybrid Connection Manager on the departmental host and add that connection; its status should read Connected.
  4. Run the connector's self-test with a real analyst's sign-in name, register it under Settings → Connectors as a Remote connector reached through a Hybrid Connection, run Test connection, and widen the tile to the Custodian role if OPIs will collect their own records.
  5. On the next ATIA or Privacy Act request, bind each OPI's repository row to its GCdocs folder — or add records yourself from the GCdocs tile — and check Source details on what arrives.

GCdocs Connector Questions

Can AccessPoint search GCdocs for an access to information request?

Yes. GCdocs runs on OpenText Content Server, and AccessPoint connects to a department's GCdocs through its OpenText Content Server connector. On an Access to Information Act or Privacy Act request, analysts choose GCdocs in the Add from… picker, browse it or search it by name, date, location or full text, and add records. Each one is copied server-side into the request with its GCdocs path, node id, version and a verified SHA-256 hash, then converted, indexed and scanned for redaction patterns like any upload. The connector only reads from GCdocs; it never writes to it.

Can OPIs retrieve their own records from GCdocs into the ATIP request?

Yes. By default the GCdocs tile is visible to ATIP coordinators, and an administrator can widen it to the Custodian role. An OPI's assignment can then carry a repository row bound to a GCdocs folder, where Browse here and Search here open GCdocs at that place; records captured there count against the row, and the OPI completes the formal attestation that its search was complete, where your office requires one. With the OTDS grant, each person sees only what their own GCdocs permissions allow, and OPI staff never see who made the request. Our guide to a reasonable FOI search sets out what the record of a search should contain.

What do we need from our department's GCdocs team to connect AccessPoint?

A request through your IT service desk or the GCdocs service desk, because API access to GCdocs is not self-service. Ask for an OTDS OAuth client with the token-exchange grant and the Content Server resource allowed — or a service account with impersonation allowed on that resource — and the login format OTDS expects, plus a read-only service account for health checks and network reach from the connector's host to GCdocs and OTDS. If the impersonation grant takes time, the connector can start on the read-only service account, with AccessPoint's own case permissions as the per-person gate, and move to the impersonating mode when the grant lands.

Can AccessPoint handle Protected B records from GCdocs?

GCdocs holds information up to Protected B, and AccessPoint's controls are designed for Protected B data in the department's own tenant. Captured records move from GCdocs to the request's storage in your Azure subscription and nowhere else: the AccessPoint API fetches them server-side, your browser never calls the connector, and Realizer never sees connector traffic. The connector keeps no document bytes — only credentials, resolved paths and hashes, in memory. Confirm with your departmental security authority that your AccessPoint deployment's own security assessment covers the records you capture; the GC security controls reference maps AccessPoint's controls to ITSG-33 to support that work.

Do we need a VPN or an inbound firewall rule for AccessPoint to reach GCdocs?

No. Because a GCdocs front end is expected to be reachable only from the GC network, the connector runs on a departmental host beside GCdocs. Microsoft's Hybrid Connection Manager on that host opens an outbound connection on port 443 to an Azure Relay in your own subscription, and the AccessPoint API reaches the connector through that tunnel. The API's TLS session runs end to end inside it, so the relay never sees the content, and the connector needs only outbound HTTPS to GCdocs and OTDS — no domain membership and no OpenText client software.

Has the connector been validated against our department's GCdocs?

Realizer validates it against your instance during onboarding. It talks to GCdocs only through OpenText's published Content Server REST API and OTDS interfaces, and supports Content Server 16.2 or later with REST API version 2. GCdocs is on the 24.3 line — the version the Canada School of Public Service's GCdocs course covers — and the connector's use of the REST API stays within what 16.2 and later expose. Some of what it relies on, such as how Content Server answers ranged downloads and folder-scoped searches, comes from OpenText's public documentation rather than a test on a live GCdocs 24.x instance; where a department's GCdocs behaves differently, the connector degrades safely. The points that differ between departments are settings: the search syntax, the address that opens a record in GCdocs and the impersonation mode your OTDS permits. Ask us about your instance.

What does the GCdocs connector cost a department?

Nothing extra from Realizer. Repository connectors are a licensed module of AccessPoint, and every plan includes it: flat annual pricing by organization size ($2,990, $7,990, $14,990 or $29,990), no per-user fees, billed through the Microsoft commercial marketplace, with a 30-day free trial. Azure is paid separately, in the department's own subscription: the Hybrid Connection at about USD $10 a month per listener at Azure list price, with 5 GB of relay traffic included, and the connector's host if you run it in Azure rather than on a departmental server.

Flat annual pricing, published in full. Every feature in every size — access requests, privacy impact assessments, breach response, complaints, video & audio redaction, the public portal, repository connectors, and AI Assist. No per-user or per-module fees.

  • Under 500 employees$2,990/yr
  • 500–1,999 employees$7,990/yr
  • 2,000–9,999 employees$14,990/yr
  • 10,000+ employees$29,990/yr

Bring GCdocs Into Every ATIP Request.

Try AccessPoint free for 30 days in your own Microsoft 365 and Azure tenant — repository connectors included, no per-connector fee.

Start Free Trial Request a Demo