If you’ve ever had two people editing the same GTM container simultaneously and ended up with broken tags or overwritten changes, you’ve hit the collaboration wall that GTM workspaces are designed to solve.
GTM’s workspace system gives teams a way to work in parallel without stepping on each other’s changes. Combined with GTM’s version history, it also gives you a reliable rollback mechanism if something goes wrong in production.
This guide covers everything: how workspaces work, how to structure your team’s workflow, merge conflict resolution, and best practices for version management.
What Are GTM Workspaces?
A workspace is an isolated working environment within a GTM container. Think of it like a branch in Git — you make changes in your workspace without affecting the live container or other people’s work until you’re ready to publish.
Default behaviour: Every GTM container has at least one workspace called Default Workspace. If your team all works in Default Workspace, you’re all editing the same draft simultaneously — the last publish wins and earlier unpublished changes can be overwritten.
With multiple workspaces: Each workspace has its own independent set of draft changes. You can develop, preview, and test your changes in isolation, then merge and publish when ready.
Important limit: GTM Standard (free) accounts get 3 workspaces per container. GTM 360 (paid) gets unlimited workspaces. For most teams, 3 is sufficient with proper workflow management.
Official reference: GTM Workspaces documentation
When Workspaces Matter
Workspaces are most valuable when:
- Multiple people work in the same container — developers, analysts, CRO team, agency
- Development and production changes need to stay separate — you’re building a new tracking implementation while the current one must stay stable
- Client approval is required before publishing — you build in a workspace, share the preview link, and only publish after sign-off
- A/B testing or phased rollouts — separate workspaces for test and control configurations
Workspaces are overkill if you’re the only person working in a container and you publish changes immediately.
Setting Up a Productive Workspace Structure
The Three-Workspace Pattern
For most teams, this structure works well within the 3-workspace limit:
Workspace 1: Default Workspace — “Hotfixes only” Keep Default Workspace clean and ready for emergency fixes. If a live tag breaks and needs an immediate fix, you don’t want to be blocked waiting for another workspace’s changes to merge.
Workspace 2: Development — Active feature work All new tracking implementations, new tags, major configuration changes. The workspace your developers and analysts work in day-to-day.
Workspace 3: QA / Staging — Ready to review When development work is complete, merge it to this workspace. This is what gets shared with the client or QA team for preview review before publishing.
Creating a Workspace
- GTM container → Workspaces tab (top navigation)
- Click + (New Workspace)
- Name it clearly (e.g.,
Feature: GA4 Enhanced EcommerceorSprint 24 Development) - Add a description of what changes are planned
Name workspaces by purpose or feature, not by person. Ann's Changes is a poor workspace name. GA4 Ecommerce Events is better — it’s clear what it contains and when it’s done.
The Daily Workflow
Making Changes in a Workspace
- Select your workspace from the workspace dropdown (top of GTM container)
- Make tag, trigger, and variable changes as normal
- Your changes are saved to your workspace only — the live container is unaffected
- Use Preview mode at any time to test your workspace’s changes without publishing
GTM Preview Mode is workspace-specific. When you enter Preview mode, it loads your container with your workspace’s unpublished changes — not the live published version. This means you can test an entirely new event structure without risking anything in production.
Checking Status
At any time, you can see:
- How many changes are in your workspace (shown in the workspace dropdown)
- Which entities (tags, triggers, variables) have been modified
- The workspace’s sync status with the live container
If the live container has been published since you created your workspace, GTM will show a sync warning — there are changes in production that aren’t in your workspace.
Merging and Conflict Resolution
This is where workspaces get tricky. If two workspaces both modify the same tag, GTM detects a conflict when you try to merge.
Step 1: Update Your Workspace Before Merging
Always sync your workspace with the latest published version before merging:
- In your workspace → Workspace Changes → Update
- GTM fetches the latest published container version
- If there are no conflicts, your workspace updates cleanly
- If there are conflicts, GTM highlights them
Step 2: Resolve Conflicts
GTM’s conflict resolution is visual but limited — it shows you the conflicting entities and lets you choose which version to keep. There’s no three-way merge like Git offers.
Typical conflict scenario:
- Workspace A modified the GA4 Config tag to add a new field
- Meanwhile, Workspace B also modified the GA4 Config tag to change the measurement ID
- When Workspace B tries to update from the live container (which now includes Workspace A’s changes), GTM shows a conflict on the GA4 Config tag
Resolution options:
- Keep your workspace’s version of the entity
- Accept the incoming (published) version
- Manually reconcile by noting both changes and applying both
Best practice to avoid conflicts: Keep workspaces short-lived. Create a workspace for a specific task, complete it within a sprint (1-2 weeks), publish, and archive. Long-lived workspaces accumulate conflicts.
Publishing from a Workspace
When your workspace is ready:
- Ensure you’re in the correct workspace
- Submit button (top right)
- GTM shows a Workspace Changes summary — review every tag, trigger, and variable that will be published
- Add a Version Name (descriptive, not just “Version 47”) and Version Notes
- Publish
The publish creates a new container version and makes your changes live. All other workspaces are then notified that the live container has changed.
Version Control and Rollback
Every time you publish a GTM container, GTM creates a numbered version snapshot. This is your safety net.
Viewing Version History
Versions tab (top navigation) → shows every published version with:
- Version number
- Date published
- Who published it
- Version name and notes (if added)
- Number of changes vs. previous version
Comparing Versions
Click any version → Compare to Published to see a diff of what changed between that version and the current live container. This is invaluable for debugging: “When did this tag stop firing?” → compare recent versions to find when the relevant change was made.
Rolling Back
- Versions tab → click the version you want to restore
- Set as Latest — this creates a new workspace with that version’s configuration
- Review the workspace (it shows the diff between old version and current live)
- Publish to push the old version live
Important: You can’t directly “undo” a publish — rollback works by publishing the old version as a new version. Version numbers always increment.
Rollback Scenario Example
You published Version 47 at 2 PM and your checkout conversion rate drops to zero immediately after. By 3 PM you’ve confirmed the issue is your new GA4 purchase event tag.
Fast rollback:
- Versions → click Version 46
- Set as Latest
- Submit → Publish (add note: “Emergency rollback — purchase event regression in v47”)
- Container is live as Version 48 (with Version 46’s configuration) within 60 seconds
The new implementation that broke things is preserved in Version 47 for post-mortem review.
Workspace Naming Conventions for Agencies
If you manage GTM for multiple clients, consistent workspace naming helps across accounts:
| Pattern | Example |
|---|---|
[Feature]: [Description] | Feature: GA4 Enhanced Ecommerce |
[Client]-[Sprint]-[Quarter] | ACME-Sprint12-Q3 |
Hotfix: [Issue] | Hotfix: Broken purchase event |
QA: [Feature] | QA: Consent Mode v2 rollout |
Similarly, version notes should be meaningful:
❌ Bad version notes:
"Updates"
"Fixed stuff"
"v2"
✅ Good version notes:
"Added GA4 Enhanced Ecommerce events: view_item, add_to_cart, purchase"
"Consent Mode v2: added ad_user_data and ad_personalization signals"
"Hotfix: removed duplicate GA4 Config tag causing double-counting"
Good version notes make debugging and auditing infinitely easier — especially when someone else takes over the account or you’re diagnosing an issue 6 months later.
GTM Environments: Separate from Workspaces
GTM also has Environments — a feature often confused with workspaces. They serve different purposes:
| Workspaces | Environments | |
|---|---|---|
| Purpose | Isolate drafts during development | Deploy specific container versions to specific contexts |
| Affects | Which draft changes are included | Which published version is loaded |
| Use case | Development workflow | Staging/production separation |
A common pattern: use a Staging Environment that loads a previous published version on your dev/staging website, while your production website loads the latest published version.
<!-- Production (default) GTM snippet — loads latest published version -->
<script>...GTM-XXXXX...</script>
<!-- Staging environment snippet — loads a specific version -->
<script>
// Different snippet URL provided by GTM Environments
// Only used on staging.yoursite.com
</script>
To set up a staging environment: GTM → Admin → Environments → New Environment → name it “Staging” → GTM provides a unique snippet to use on your staging site.
The Bottom Line on GTM Governance
GTM containers can become a liability — hundreds of tags added over years, no documentation, no one sure what’s still active, breakages that take days to diagnose. Workspaces, version control, and clear naming conventions are the foundation of a container you can actually maintain and trust.
The investment in good GTM governance pays back every time you need to diagnose an issue quickly, roll back a breaking change, or hand a container to a new team member who can understand what’s in it without a 3-hour onboarding call.
We audit and reorganise GTM containers for agencies and in-house analytics teams — cleaning out dead tags, documenting active implementations, and setting up workspace workflows. Book a free consultation to discuss your container setup.