A client access request should identify the platform, the work requiring access, the person receiving it and the permission needed. Track invitations separately from verified access. Before kickoff, test the required task, record unresolved restrictions and name who will remove or review access when the engagement changes or ends.
- Define the taskIdentify the actual work needing access.
- Name recipientIdentify who will receive the permission.
- Request needed roleChoose the capability supporting that task.
- Test readinessVerify the recipient can complete it.
An invitation and a successful sign-in do not establish delivery readiness.
Define the task before asking for access
An agency often asks for broad access because a project description is broad. Reverse that order. Identify the task first: review a report, publish an approved asset, configure a connection or manage a specific account. Then decide what permissions the task needs.
The client should understand why access is requested and who will receive it. If an agency owner receives every invitation and later shares access informally, the access record stops describing who can actually act.
Build a request register
| Field | What to record | Why it matters |
|---|---|---|
| Platform and account | Exact workspace or account | Avoid access to the wrong entity |
| Task | Work requiring access | Explain the request |
| Recipient | Named person or approved service identity | Establish accountability |
| Permission | Necessary role or capability | Limit unnecessary authority |
| Client approver | Person able to grant access | Route the request correctly |
| Verification | Required task tested and result | Distinguish invitation from readiness |
| Review point | Engagement change or offboarding owner | Keep access current |
Different platforms use different role names. Confirm the actual capability represented by a role rather than assuming “editor” means the same thing everywhere.
- Platform and accountIdentify the exact workspace or account.
- Recipient and approverConnect accountable recipient with grant authority.
- Necessary permissionRecord the role or capability needed.
- Verification and reviewTest task readiness and name future review point.
Role names can represent different capabilities across platforms.
Make the request easy to fulfill
Send one clear request to the correct client contact. Include the account reference, intended recipient and the task access will support. Avoid a vague request for “all logins.” Where the platform provides invitations or delegated access, use its current supported process.
If the client cannot identify the account owner, record that as a blocker. Do not ask a less appropriate contact to bypass the process. The project owner can decide what work can proceed while the access question is resolved.
Verify what was actually granted
An invitation email is not proof that the intended person can complete the intended task. Have the recipient accept it and test the task without making an unnecessary production change.
- Invitation sentRequest is issued but not yet verified.
- Recipient acceptsThe named person enters the intended account.
- Task testCheck the required work without unnecessary production changes.
- Restriction foundRoute correction to the access owner.
Test the intended task in the correct account or workspace.
For example, a reporting engagement may require viewing a specific property. The recipient could be able to sign in while still seeing the wrong property or no relevant data. Record the result of the actual check and route the correction to the access owner.
If access allows more than the task requires, discuss whether a narrower role is available. If a broad role is unavoidable, document the reason and how use will be controlled. This is a review question, not evidence that every vendor supports every restriction.
Handle temporary access and unavailable people
Name who can resolve a blocked invitation when the original recipient is absent. Avoid solving an unavailable-person problem by spreading one person's login to the team. Update the recipient or process through the appropriate account owner.
For a short engagement, decide when access will be reviewed or removed. An intended end date only helps if someone is responsible for acting on it. The access offboarding guide provides the closeout record.
Keep the register connected to delivery
The project should show which required access is ready, which is pending and which work is blocked. Keep sensitive access details in the appropriate restricted place; a general project view can show readiness without exposing credentials.
- Ready accessRequired task has been tested.
- Pending accessRequest or acceptance still needs action.
- Blocked workShow delivery that cannot proceed.
- Repeated failureImprove wrong invitations, excessive roles or untested readiness.
A project view can show readiness without exposing credentials.
Review repeated failures: invitations to the wrong address, excessive roles, access marked ready without testing, and permissions left after staff changes. Those are concrete process improvements. A completed checklist is useful only when it reflects what people can actually do.
Questions and answers
Does an invitation mean onboarding access is complete?
No. The intended recipient must accept the invitation and verify the required task in the correct account or workspace. Record that result. A successful sign-in can still leave the agency without access to the property needed for delivery.
Should agencies request administrator access by default?
Define the task and check which role supports it. If broader access is necessary, document why and who will review its use. Platform permissions vary, so confirm the current role behavior instead of assuming a narrower option always exists.
Who removes access when the engagement ends?
Name an access closeout owner and the client contacts needed to remove or transfer permissions. Include that responsibility in the project record. The agency may be able to remove its own access in some systems; other changes require the client’s account owner.