Google Drive
Drive can be connected so documents live there rather than only in the platform.
Where to find it
Architect Panel → Integration & Connections:
- Google Registrations — the Google connection, its credentials and scopes
- OAuth Tokens — the tokens issued against it
Architect Panel → Data:
- File Stores — where files are held
- Documents — the documents involved
Your credentials, not ours
The connection uses a Google client you register yourself — a client identifier, a secret, and the scopes you request. So the arrangement is between your organisation and Google, on your terms, in your own project.
That is more setup than a one-click connector and it is the right arrangement: your data stays under an agreement you control, and you can see and revoke the access from your own Google console.
Scopes are what you are asking for
Request the narrowest that does the job. Google shows users what is being requested, and a request for broad access to everything in someone's Drive will be refused by people who read it — reasonably.
Broad scopes also take longer to get through Google's own verification if you go through it.
Authorisation is per user
Each person authorises the connection for their own account, and it acts as them. That is usually right — files land in their Drive with their permissions — and it has two consequences worth planning for.
First, a person who has not authorised cannot use the feature, so onboarding includes a step people must complete themselves. Second, when somebody leaves, what they authorised goes with their Google account — anything depending on it stops.
Where that matters, use a service account
Shared or automated storage should not hang off an individual's authorisation. Where files must remain accessible regardless of who is employed, connect an account belonging to the organisation rather than to a person.
Decide where the file of record lives
The question to settle before going live: is Drive the system of record for these documents, or a convenience copy?
If Drive, then your retention, access control and disposal happen there, and the platform's own controls do not cover them. If a copy, be clear about which one is authoritative — a document edited in Drive and referenced here is a divergence waiting to be noticed at the worst moment.
Access lives in two places now
A file in Drive is governed by Drive's sharing, not by the platform's permissions. Somebody with no access to a record here may still have access to its document there if it was shared, and that is easy to overlook when reviewing who can see what.
Worked example
A team connects Drive with read and write on a specific folder rather than a broad account scope, using an organisational account. Documents generated here are filed to a shared folder governed by Drive sharing, and the retention policy explicitly names Drive as the system of record for them.
Recommendations
- Register your own Google client and request narrow scopes.
- Use an organisational account for anything shared or automated.
- Decide where the file of record lives before go-live.
- Remember access is governed in two places when reviewing.