GTM Workspaces and Versions: Publish and Roll Back

This guide is built from Google's Tag Manager Help articles on workspaces, publishing, versions and approvals and users and permissions. For what containers, tags and triggers are, see our Google Tag Manager basics; for testing a draft before it goes live, see GTM preview mode.

What a workspace is

Google describes a workspace as something that "allows you to create multiple sets of changes for your container." Every change you make in Tag Manager is made in one: "Every time you make changes to a container, you're making those changes in a workspace."

Workspaces matter as soon as more than one person, or more than one project, touches the same container. Each person or project works in its own workspace, so, in Google's words, it "helps prevent teammates from inadvertently publishing someone else's unfinished changes." A workspace is the draft; a version is what the draft becomes when it is saved or published.

When a workspace is versioned or published, Google says "its name, notes and list of changes will be recorded with the version. The workspace is then removed." The default workspace is recreated straight after, so there is always one to work in.

How many workspaces you get

On a free account that limit is reached quickly when an agency, a developer and an in-house marketer each keep a workspace open. Publishing or versioning a custom workspace removes it and frees the slot; an unfinished one can be deleted (see below).

Creating, switching and removing workspaces

To create your first custom workspace:

1. Open the Overview tab.
2. In the Pending changes section, open the workspace menu and choose Manage Workspaces.
3. Click Add in the upper right corner of the Workspaces page.
4. Enter a name and description, then click Save.

Once a custom workspace exists, you create more and switch between them from the Current Workspace menu in the left navigation. To remove one, open the workspace list, click Info next to it, then More Actions and Delete.

Choose the name with care. Google notes that "The workspace name and description may later become the version name and version description," and gives "New Floodlights for Q1" as an example. A name that says what the change is, such as "Contact form conversion tag", makes the version history readable months later.

Out-of-date workspaces and conflicts

A container has a single line of versions: "Each container has one stream of versions." When anyone publishes or saves a version, every other open workspace is marked as out of date and prompted to update.

If you try to publish an out-of-date workspace, Tag Manager shows: "This workspace is out of date. It will be updated automatically if you proceed." To update it yourself, click Update Workspace, review the list of unmerged versions and click Update. That brings in every change made in other versions since your last update.

If the same item was changed in both places, the Workspace Overview page shows "Conflict found". Select Resolve conflicts to open a side-by-side view: the latest synced version on the left, your workspace on the right, with highlights:

For each conflict you either ignore the change from the synced version or copy it in; Resolve All ignores them all. Be careful with that button: when the workspace is later published, "any changes from the latest synced version that have been ignored are overwritten with the changes in the current workspace." In other words, ignoring a conflict can quietly undo a colleague's published fix.

Versions

Google's definition: "A version is a snapshot of a container configuration at a particular time." Two things create one:

• Publishing. "Every time a container is published, a version of that container is recorded."
• Saving without publishing. Click Submit, choose Create Version, enter a name and description, and click Create. This is useful for a change that is ready but should wait, for example until a campaign starts.

A new container starts with an automatic version called "Version 1 - Empty Container". The Versions page also keeps a publish history, so you can see "when versions were live and who published them" from the entries with a date in the Published column.

Publishing

1. In the workspace, click Submit at the top right.
2. Select Publish and Create Version if it isn't already selected.
3. Review the Workspace Changes list. From its More Actions menu you can view the differences for each item or abandon a change; clicking an item opens it for last-minute edits.
4. Enter a Version Name and Version Description.
5. If the container uses several environments, choose one under Publish to Environment (see our GTM environments guide).
6. Click Publish.

Publishing makes the changes active for the chosen environment; without environments, that is your live site. Before step 1, test the draft in preview mode: preview shows the draft only to you, publishing shows it to every visitor.

Tag Manager 360 adds approvals. Users with Edit access or higher get a Request Approval option on Submit, can choose an approver and add a comment, and anyone with Approve or Publish access can then Approve, Send Back or Withdraw the request on the Approvals tab. The free version has no approval step, so the permission levels below are the only gate.

Rolling back to an older version

Google's example of why versions exist: "If someone accidentally publishes a container version before it's ready for production, you can revert your workspace to an earlier version and publish it." There are two ways to do that:

The first is the emergency route when a published change breaks the site or tracking. The second is for when you want the old setup back but still need to fix something before it goes live. Either way, the broken version stays in the history, so you can open it later to see what went wrong.

Who can do what

Container permissions decide who can create workspaces, versions and publishes:

Account Admins inherit Read on every container in the account and can give themselves more. Google also recommends at least two account administrators, because with only one "you may lose access to your tags if that user becomes unavailable." On Tag Manager 360, Google suggests container owners "may choose to grant Publish access to a smaller set of more experienced users."

How we work with workspaces

This is our own practice, not Google guidance:

• One workspace per change, named after what it does, so the version history reads as a changelog.
• We update a workspace right before publishing and read every conflict instead of using Resolve All.
• On client containers we ask for Edit or Approve access, and the client keeps Publish and Admin, unless they ask us to publish.
• Before a larger change we note the current live version number, so a rollback is one click if anything breaks.
• After publishing we check the live site and the reports, as described in our preview guide.

Frequently asked questions

How many workspaces can a GTM container have?

On a free account, 3 at a time: the default workspace plus 2 custom ones. Tag Manager 360 accounts can create an unlimited number.

What happens to a workspace after I publish it?

Its name, notes and changes are recorded with the new version, and the workspace is removed. If it was the default workspace, a new default workspace is created.

How do I roll back GTM to a previous version?

Go to Versions, open the version you want and publish it from the Actions menu. To edit it first, choose Set as Latest Version, which replaces the current draft with that version.

Why does GTM say my workspace is out of date?

Someone published or saved a version from another workspace. Update the workspace to merge those changes in, and resolve any conflicts before you publish.

Who can publish in Google Tag Manager?

Only users with Publish permission on the container. Approve can create versions but not publish, Edit can only make changes in workspaces, and Read can only look.

For more on tagging, see our guides to GTM triggers, GTM variables, the data layer and server-side tagging.