How To Grant Google Tag Manager Permissions: 2026 Guide
Table of Contents
Google Tag Manager assigns access at two levels: an account role and permissions for each container, as per Google’s permission documentation. Account roles are User or Administrator. Container permissions are No access, Read, Edit, Approve, or Publish.
These settings control different things. A person can be an account-level User while holding Publish permission for one container, and an Administrator doesn’t automatically receive Publish permission for every container. Getting this distinction right is what keeps you from either locking out a collaborator who needs to work or handing out more access than the job requires.
Which access should you grant?
- Needs only to inspect the setup: Read.
- Needs to build and test tags: Edit
- Needs to create release versions: Approve
- Needs to deploy changes: Publish
- Needs to manage users or create containers: Administrator, plus whatever container permissions the work requires
Key Takeaways
- Account role and container permission are separate assignments. Neither automatically grants the other, outside of the Google Marketing Platform’s specific Admin-inherits-Read behavior.
- Approve lets someone create a version themselves; it doesn’t create an automatic review-and-approve workflow on someone else’s changes.
- Only the Publish permission can deploy changes live directly. Edit and Approve can’t push something live themselves, but errors introduced at those levels can still end up published by someone else, so review matters at every level.
- Losing your only Administrator isn’t a support ticket away from being fixed: the account or container auto-deletes, with a 30-day window to export from the trash if you still have read access. Keep at least two Administrators to avoid this entirely.
- Revoking at the account level removes everything; revoking at the container level removes only that one container.
Account Role vs. Container Permission
Both scopes are managed in the same place: Admin → User Management, either the Account column or the Container column, depending on what you’re adjusting. Use the lowest permission that lets the person do their actual job.
Ordinary account Users don’t automatically inherit any container access; that has to be assigned per container. Account Administrators can grant themselves access to any container in the account, since handling permissions is part of what Administrator status allows, but that’s a capability, not an automatic content grant. One exception: if your organization uses Google Marketing Platform (GTM 360) with enterprise user groups, Admins in that specific setup do automatically inherit Read access across all containers. That’s a Marketing Platform behavior, not how standard GTM works.
Permission Matrix
| Scope | Permission | What it allows | Suitable use |
| Account | User | Basic account visibility; container access assigned separately | Most collaborators |
| Account | Administrator | Can create containers and modify user permissions for the account and its containers | A small number of internal owners |
| Container | No access | Container isn’t visible to the user | Anyone who doesn’t need that container |
| Container | Read | View tags, triggers, and variables without changing them | Auditors and stakeholders |
| Container | Edit | Create workspaces and make edits; cannot create versions or publish | Implementers building and testing tags |
| Container | Approve | Everything Edit allows, plus creating versions; still cannot publish | Reviewers preparing a version for release |
| Container | Publish | Everything above, plus deploying versions live | Trusted production deployers only |
A note on Approve specifically, since the label invites a wrong assumption: it doesn’t create a formal two-person review queue on its own. It just means the person can create a version themselves, but can’t publish it. If you want an actual review step where one person’s changes get checked before another person deploys them, that’s a workflow your team enforces (someone with Edit builds it, someone with Approve packages it into a version, someone with Publish signs off and deploys), not something GTM enforces automatically.
Only Google Accounts can be granted access. These include Gmail addresses, accounts managed through Google Workspace account, and other email addresses registered at accounts.google.com. A non-Gmail email can still work here as long as it’s registered as a Google Account; what can’t receive access is an email with no Google Account behind it at all.
Add Access at the Account Level
- Click Admin.
- In the Account column, select User Management.
- Click +, then Add users.
- Enter one or more email addresses.
- Set Account Permissions: User is the default and grants basic account visibility; choose Administrator if the person needs to create containers or manage other users’ permissions.
- Optionally set Container permissions right away for any containers this person should access immediately.
- Click Invite. Each person receives an email invitation and an entry on the Accounts page’s Invitations card; access is granted once they accept.
When bringing on an external contractor or agency partner, container-level-only access, without an account role, keeps their visibility limited to the specific containers they’re working on. As an organizational policy, keep account administration with trusted internal owners and give agencies or contractors access only to the containers and functions they need.
Add Access to One Container
- Click Admin.
- In the Container column, select User Management for the specific container.
- Click +, then Add users.
- Enter the person’s Google Account email.
- Assign the container permission: Read, Edit, Approve, or Publish.
- Click Invite.
Use Read for auditors and stakeholders who need visibility yet cannot change anything. Active implementers, whether internal or agency, generally fit Edit, so they can build and test, but cannot push changes live. Reserve Publish for the specific people responsible for production deployment; anyone with Publish can deploy without further sign-off.
Change or Revoke Access
Go back to Admin → User Management, in whichever column (Account or Container) corresponds to the access you’re changing.
- To adjust someone’s level: select their entry, change the permission, and save.
- To revoke access entirely, remove someone from Account User Management to revoke their account role and all container permissions associated with it. Removing someone from a specific Container’s User Management only revokes access to that container; it doesn’t affect their account role or access to other containers. If you want someone completely gone from the account, remove them at the account level, not just from individual containers.
- To confirm a change took effect: refresh the User Management list and check that the entry reflects the new permission, or is gone entirely if you removed access.
When an agency relationship or contractor engagement ends, revoking their access is offboarding work, not an optional cleanup step. A former collaborator with lingering Edit access can continue altering configurations, while someone with Publish access can deploy changes directly to your site.
If You Lose Your Only Administrator
Google’s own policy here is strict: support cannot add users to your account to route around a lockout, so if your account is left with zero Administrators, nobody, including Google, can grant access back in through the normal permission system. Concretely, according to Google’s own documentation, an account or container left with no admin is automatically deleted, and any remaining users with Read access get a 30-day window to export the container from the trash before it’s gone for good. Recovery means importing the exported container into a new account with Administrator rights, not a quick fix in the old one.
This is exactly why maintaining at least two active Administrators is the strongest protection against a lockout that GTM cannot reverse through its normal permission system. Make sure the Google accounts involved are managed by people within your organization instead of only by an external agency or consultant, since losing contact with an external admin poses the same risk.
Security and Offboarding Checklist
- Grant the lowest permission that lets someone do their actual job (least privilege).
- Keep at least two Administrators on every account at all times.
- Review the full access list on a regular cadence, quarterly is a reasonable starting point, and immediately after any personnel or agency change; adjust frequency up for higher-risk accounts.
- Use Edit for implementers, Approve for the person packaging a version, and Publish only for whoever deploys, if you want a review step before anything goes live.
- Revoke access at the account level (not just for individual containers) when someone’s engagement ends.
- Document who has access, when it was granted, and why, particularly for temporary contractors or seasonal help, so a later audit doesn’t require guesswork.
Getting this wrong has consequences, but they’re specific, not vague: a person with Publish permission who deploys a misconfigured tag or trigger can interrupt or duplicate conversion tracking, which affects reporting and anything (like automated bidding) that depends on that data until it’s caught and fixed. Data that wasn’t collected during the outage generally can’t be recovered after the fact. Edit and Approve cannot deploy changes directly, but people at those levels can still introduce configuration errors that someone with Publish permission later releases without realizing it, so review matters at every level, not just at the point of deployment.
Handling Permissions via the API
For organizations managing access across many containers, the Tag Manager API supports programmatic permission management rather than clicking through the UI account by account. The resource is user_permissions, and the relevant methods are:
- accounts.user_permissions.List, retrieve all permissions for an account
- accounts.user_permissions.get, fetch one user’s permission details
- accounts.user_permissions.create, add a new access programmatically
- accounts.user_permissions.update, modify an existing permission
- accounts.user_permissions.delete, revoke a user’s access
These sit under the base path https://tagmanager.googleapis.com/tagmanager/v2/accounts/{account}/user_permissions and require the https://www.googleapis.com/auth/tagmanager.manage.users OAuth scope. This is useful for building custom onboarding, offboarding, or audit workflows around your own identity systems; it isn’t, on its own, a turnkey integration with an enterprise identity provider, which would still need to be built.
Frequently Asked Questions
Do I need a Google account to be added to Google Tag Manager?
Yes. It needs to be a Google Account specifically, Gmail, an account managed through Google Workspace environment, or any account registered at accounts.google.com. A non-Gmail email address works fine as long as it’s registered as a Google Account; what doesn’t work is an email with no Google Account behind it at all.
Why can’t I see the User Management option in GTM?
You most likely don’t have Administrator access for that account. Only Administrators can add or manage other users, or modify permissions for the account and its containers. Ask whoever manages the account to add the new user directly, or to upgrade your role to Administrator.
What’s the difference between Account and Container permissions in GTM?
Account roles control account administration. Container permissions control what someone can do within each individual container. A person can hold an account-level User role while still having Publish rights on a specific container.
How do I remove someone’s access to Google Tag Manager?
Go to Admin → User Management. To remove them entirely, do so from the Account column; that revokes their account role and all container permissions tied to it. To remove access to just one container while leaving the rest intact, remove them from that specific Container’s User Management instead.
Can a user see my GTM container but not make changes to it?
Yes, that’s Read access: they can view containers, workspaces, tags, triggers, and variables, but can’t edit, create versions, or publish anything. To let them start making changes, upgrade them to Edit, Approve, or Publish, depending on how much you want them to do.
Correct GTM permissions protect the workflows behind your conversion tracking. If you need help auditing tags, validating conversion events, or structuring access for a paid media team, learn more about Black Propeller’s measurement and paid media services.
