Start with the operation you need to test
An initial assessment can usually start with a process walkthrough, field names and a few redacted or synthetic examples. Connecting live accounts becomes useful when a specific question needs evidence from the actual tool: can an approved record be read, can a draft be created, or can one permitted update reach its destination?
Ask the consultant to name that question before requesting access. “We need administrator access to integrate your systems” leaves the operation, data and removal process undefined. A useful request explains the identity, permission, environment, purpose and point at which the grant can end.
Use an access ladder for the engagement
The table is a commissioning recommendation, not a permission model built into every platform. Choose the lowest stage that can answer the current question. An assessment does not automatically authorize implementation, and permission to read does not authorize a live write.
| Stage | Starting access | Evidence before expanding it |
|---|---|---|
| Workflow assessment | Walkthrough and approved redacted or synthetic samples | The unanswered question actually requires a tool connection |
| Connection experiment | Named identity in an approved test workspace; only the required operation | Observed result, actual granted permissions and any platform limitation |
| Pilot drafting | Read the agreed source and prepare output in a restricted destination | The owner can inspect the input reference and review the draft |
| Pilot write | One agreed operation in one approved destination, with its approval rule | The owner accepts the write check, recovery path and removal plan |
Keep the accounts and runtime under client control
Prefer a workspace, project and repository controlled by your organization, with the consultant invited through their own identifiable account. The client should retain the ability to administer the environment, see its costs and remove the invitation. If a provider-managed environment is necessary, state what can be exported, who holds the account and what changes when the engagement ends.
Distinguish the consultant’s login from the identity used by the running workflow. Removing a person from a workspace may leave a service account or application grant active. Conversely, a workflow built on the consultant’s personal login may stop when that person leaves. Agree which runtime identity the client will control before accepting ongoing operation.
For Google Cloud specifically, its service-account guidance recommends dedicated accounts for each application and documenting a contact person and relevant documentation. That is a useful model for making a runtime identity understandable; it does not make the same account type appropriate for every SaaS tool.
Check the real permission, including read access
Read-only access can still expose confidential information. Check the records, fields and attachments visible to the granted identity, including items outside the pilot. A written promise to read one folder is weaker than a control that actually limits access to that folder.
Google’s OAuth guidance says to request the smallest, most limited scopes needed for a task and to request additional access when its feature is needed. Apply the same question to the actual platform: what is the narrowest available grant? Some tools offer coarse permissions. When they cannot enforce the proposed boundary, use an isolated workspace or approved samples, narrow the experiment, or leave the connection untested.
The consultant can explain required permissions while the authorized client administrator reviews and grants them. Use the platform’s invitation or authorization flow rather than sharing the administrator’s password. Store application credentials in an appropriate secret store; the project brief, chat and repository are places for references, not secrets.
Write one access record that can be closed
Keep a small register alongside the pilot scope. Record the human and runtime identities, client access owner, environment, accessible data, allowed operations, secret-storage location without the secret, review or expiry point, and removal steps. Include who checks the result. Record the permissions actually granted, especially if they differ from the request.
In a synthetic example, a request-to-task pilot reads approved requests from a test queue and creates drafts in a test board. Its record names those locations, excludes customer attachments and keeps live-board writes disabled. If the platform cannot restrict the queue, that is a reason to adjust the test before granting wider access. This example describes a proposed design, not a deployed customer integration.
Rehearse removal without breaking unrelated work
Plan the end state first: is the pilot stopping, or will a client-owned workflow continue? For a continuing workflow, remove the consultant’s human access and check that the client can still operate the approved route. For a stopped pilot, disable its triggers and remove the relevant runtime grants as well. Perform the exercise in the approved test environment and retain the observed result.
Check the provider’s revocation semantics before pressing a button. Google’s web-server OAuth documentation says that revoking a combined authorization removes all its scopes on behalf of the associated user. Its token-revocation section also describes invalidating tokens for the project’s registered clients. Do not assume that revoking one token affects only one feature; inspect whether another workflow relies on that user’s authorization.
After removal, verify the intended blocked access and the owner-visible outcome of a workflow attempt. A disconnected badge alone does not prove that every invitation, key or application grant is gone. Record anything that could not be checked and who will resolve it.
Close data handling separately from access
Revoking a credential does not establish that previously copied data has been deleted. Agree where samples, logs, exports and backups may be held, who may retain them, and what deletion or retention evidence the client expects. Keep required audit material under the agreed policy. Confirm provider capabilities instead of promising deletion from systems you cannot inspect.
A good first brief needs the task, the two systems and the operation you want to prove. If access is still uncertain, use a workflow assessment to resolve the boundary before commissioning a live connection.
The request-to-task example is synthetic. The access ladder and client-control recommendations are the author’s commissioning guidance. Provider documentation is platform-specific; no customer access exercise, legal assurance or certification is claimed.