Workspaces in Google Tag Manager: team collaboration without conflicts
Two people editing the same container used to mean someone's changes got overwritten. Workspaces exist specifically so that stops happening.
A workspace is a draft of container changes - editable, shareable, and separate from what's currently live. Multiple workspaces let multiple people (or agencies) change the same container in parallel without stepping on each other; a version is the read-only, published snapshot created the moment a workspace goes live. Conflicts only surface at publish time, when GTM compares the workspace against whatever else has published since it was created - and it shows you exactly what changed before forcing a choice.
What a workspace actually is
Every container starts with a Default Workspace, but nothing stops you from creating more. Each workspace holds its own draft of tag, trigger, and variable changes, invisible to other workspaces until published. This is what makes GTM's Preview mode meaningful - you're previewing one workspace's draft state, not "the container" in some vague sense.
Why multiple workspaces exist
The moment more than one person - an in-house marketer and an outside agency, say - needs to make independent changes to the same container at the same time, a single shared draft becomes a liability: one person's half-finished experiment can accidentally get published by someone else hitting Submit on their own unrelated change. Separate workspaces isolate each person's in-progress work until it's ready.
Merge conflicts
A conflict happens when two workspaces touch the same tag, trigger, or variable and one gets published before the other. GTM detects this automatically at publish time and shows a side-by-side comparison of the conflicting element in both workspaces, requiring an explicit choice - it does not silently pick one or merge them automatically.
| Situation | What GTM does |
|---|---|
| Two workspaces edit different elements | Both publish cleanly, no conflict |
| Two workspaces edit the same element | Second publish attempt shows a conflict comparison, requires a choice |
| A workspace is stale (container changed since it was opened) | GTM flags it before you can publish, so you're aware before conflicts arise |
Practical governance
- Name workspaces after the change they contain ("Q3 - Meta CAPI rollout"), not generically ("New Workspace 4").
- Delete a workspace once it's published - it has served its purpose and only adds clutter.
- Agree on who publishes, even if several people draft - fewer publish events means fewer conflicts to resolve.
Common questions
What's the difference between a workspace and a version in GTM?
A workspace is an in-progress draft of changes, editable and re-editable until published. A version is a read-only snapshot created automatically at the moment of publishing - it's what you roll back to if a published change causes a problem.What happens if two people edit the same tag in different workspaces?
GTM detects the conflict when the second workspace is published and shows a side-by-side comparison of both versions of the changed element, requiring the publisher to explicitly choose which change to keep before the publish can complete.Should I delete a workspace after publishing it?
Yes, as a matter of hygiene - a published workspace has done its job and serves no further purpose except as accumulated clutter that makes it harder to see which drafts are actually active. Deleting it does not affect the version that was already published.
Multiple Agencies or Teams Touching One Container?
We set up a workspace and publish discipline that keeps parallel changes from colliding.
Get Container Governance Help