Before you give access to Google Tag Manager, identify the container installed on the client’s website and decide who will publish changes. “Add us to GTM” leaves both decisions unresolved.
Record the account name, container ID such as GTM-XXXXXXX, website, agency email, and publishing owner. If web and server containers are involved, list each separately in the request.
How the account owner gives access
In Tag Manager, open Admin → User Management in the Account column. Select + → Add users, enter the recipient’s Google Account email, choose account permissions and the required container permissions, then select Invite.
For a specific container, use User Management in the Container column and assign its permissions there. The recipient accepts the invitation before verifying access. These are Google’s documented invitation routes.
Before inviting, ask the agency whether it will only audit, prepare changes for review, or release changes to production. This makes the permission choice a work decision instead of a guess.
Recommended account and container permissions
Account User access covers basic account information; Administrator can manage users and create containers. Container permissions are separate:
| Container role | Capability |
|---|---|
| Read | Inspect configuration |
| Edit | Change configuration and create workspaces |
| Approve | Also create versions, but not publish |
| Publish | Release changes as well as edit and create versions |
These distinctions come from Google’s permissions reference.
Our recommendation: use Read for an audit, Edit when another person handles releases, and Publish only for the person responsible for deployment. Request account administration when user or container administration is part of the engagement. Do not use Admin as a shortcut around an unclear publishing process.
How the agency requests GTM access
Send a request with two explicit lines: account role and container role.
Please invite [Google Account email] to Tag Manager account [name], with User account access and Edit permission on container [GTM-ID] for [website]. We will prepare the tracking changes; [client publishing owner] will review and publish them. Please confirm if a different container is installed on the production site.
Then complete these agency-side checks:
- Accept the invitation using the requested Google identity.
- Match the visible container ID to the website implementation with the client’s developer.
- Review the live version and any unfinished workspaces before making changes.
- Record the publishing owner, reviewer, and first planned release date.
If the agency is responsible for deployment, change the request to Publish and state that responsibility. If the client cannot identify the installed container, resolve that with the developer before creating another one.
Common Google Tag Manager client access problems
The account appears, but the required container does not
Ask the administrator to inspect the permissions on the exact container in your request. Account User access alone does not supply container permissions. Google’s user-management reference distinguishes the two levels.
You can edit, but cannot publish
Check whether this is intentional. If the client retains release control, prepare a change summary and hand it to the publisher. If nobody owns publishing, assign an owner before promising a tracking launch date.
The invite went to another Google identity
Have the administrator verify the destination email. Open GTM with the agreed work identity and check for a pending invitation. Avoid accepting access into a personal account simply because it is already signed in.
The previous agency has the only administrator
Ask for a documented handover while that contact is still available. Recommend two active client-side administrators; Google also recommends multiple administrators to prevent lockout in its account-management guidance. Escalate a missing administrator as a handover blocker instead of treating it as a routine invitation delay.
Security and publishing checks
Tag changes can affect website behavior and measurement. Before the first release, agree on who reviews the change, which test proves it works, and which earlier version is the rollback candidate.
Keep credentials personal to each authorized work user and enable two-step verification. Use a dedicated workspace for the assignment, describe what changed, and review tags and triggers before publishing. Never publish a container simply to test whether your access works.
For a form conversion, useful evidence includes the test submission, expected tag behavior, form receipt, and a check for duplicate firing. If the task also requires Analytics configuration, request GA4 access separately. After release, add the conversion path to the ongoing monitoring checklist.
Simplify multi-client access requests
Agencies can automate client account access for supported Google products with LeadUp’s reusable connection link. This gives clients one guided flow for Google Ads, Analytics, and Tag Manager instead of separate instruction emails.
For GTM, configure both account and container permissions directly in LeadUp. Your client can complete the access request through the same onboarding link. After connection, verify that your specialist can open the intended container with the role agreed for the assignment.