Clear search
Close search
Google apps
Main menu


Use workspaces to manage multiple sets of tag changes.

In Google Tag Manager, workspaces enable you to create multiple and differing sets of changes to your container. Different users and teams can work on these sets of changes in separate workspaces to independently develop and test tag configurations. This feature helps with version control by enabling you to roll back certain changes, and can help prevent teammates from inadvertently publishing each other’s changes.

It’s recommended that you use workspaces for smaller sets of changes whenever possible. This will make your container’s version history more robust, make rollbacks easier, and reduce the complexity of updating your workspace.

In this article:

When to create a new workspace

A workspace is a place to work on a set of changes that will become a version.

You may wish to create a workspace for situations where you want to develop and test tag configurations separately from your main production tag configurations, or when you have multiple users working on tag configurations.

Each container has one stream of versions. When a new version is created, each workspace will display a notification that the workspace is out of date, with a prompt to update the workspace.

When a workspace is versioned or published, its name, notes and list of changes will be carried over to the version. The workspace is then removed. The default workspace will be recreated after it is versioned or published.

Managing workspaces

To create a new workspace, switch to a different workspace, or remove an existing workspace, go to the Workspace Overview page (click Workspace in the top navigation bar) and then click Manage Workspaces from the the Now Editing card.

Click + in the upper right corner of the Workspaces Screen to create a new workspace, and enter a name and description. The workspace name and description will later become a version name and description. Establish a meaningful naming scheme that reflects the objectives of the workspace. For example: "New Floodlights for Q1", "Updated Google Analytics for Q2", etc.

To select a different workspace, simply click it from the list. Large lists can be narrowed by clicking the search icon in the upper right corner and entering a term.

To remove a workspace, from the Workspaces Screen, click the info icon (“i”) to the right of the desired workspace, and then select “Delete” from the dropdown menu in the upper right corner.

Tag Manager 360 customers will be able to create unlimited workspaces in their containers. Users of the standard version of Tag Manager will be able to have up to three concurrent workspaces, consisting of a default workspace and two custom workspaces.

Updating workspaces

When working with multiple workspaces, any given workspace may become out of date with the changes happening elsewhere in the container (i.e. when a new version is created).

Updating the workspace will bring in any changes that have been made in versions of the container since the last update. If any of these changes conflict with changes already made in the current workspace, users will be shown the conflicts and asked to resolve them.

Updating is optional while working on changes in a workspace, but the workspace must be updated before creating a version and publishing from it. If a workspace is not updated, it will automatically update when you attempt to publish or create a version.

Resolving conflicts

If there any conflicts between the changes synced to your workspace while updating and any of the changes already in your workspace, you will see a “Conflict found” indication on the Workspace Overview page. Selecting to resolve the conflicts will bring you into a conflict resolution tool.

For each entity in your workspace where a conflict has been found (i.e. each tag, trigger, variable, etc.), you will be able to resolve conflicts one field at a time. The configuration of the entity in the latest synced version is shown on the left, and the configuration of the entity in the current workspace is shown on the right. Each conflict is highlighted, and the color of the highlighting indicates the nature of the conflict:

  • Blue: Something has been modified between the latest synced version and the current workspace.
  • Red: Something from the latest synced version is not present in the current workspace.
  • Green: Something from the current workspace is not present in the latest synced version.

For each conflict, you can decide whether to ignore the change from the latest synced version or copy the change from the latest synced version. Selecting Resolve All will ignore all the changes from the latest synced version. Once all of the conflicts have been resolved, you can save the entity. If there are any other entities with conflicts, you’ll be able to repeat this process for each one.

When the current workspace is versioned or published, any changes from the latest synced version that have been ignored will be overwritten with the changes in the current workspace.

Best practices

We suggest to follow these best practices to help you streamline your workspace management:

  • Create a workspace for each set of changes that are related and will be published at the same time. For example, you might work on the tags, triggers, and variables for an initial deployment of Google Analytics pageview tags in one workspace, but work on the configuration of Google Analytics event tracking tags in a separate workspace.
  • Use separate workspaces for different tagging projects. For example, if you have an agency working on both a deployment of Google Analytics and a deployment of DoubleClick Floodlight tags, it’s recommended to use at least two workspaces to keep the configurations separate. This will allow you to publish tags in a controlled order, and will make your version history clearer.
  • It may be helpful to have different teams or individuals working in separate workspaces. Additionally, each team or individual may have more than one workspace for different sets of changes.
  • When publishing and/or creating a version, enter a Version Name and Description that will make it easy to know what changes are being made. For example:
        Version name: "GA page view tag initial launch"
        Description: "Launch the Google Analytics page view tag on"
  • Workspaces are useful for testing changes without risk of someone else accidentally publishing your work. You can use a workspace as a sandbox to try out, preview, and debug new things on your site or app. If you choose not to publish them, you can opt to save the workspace for later reference, or simply delete the workspace.

Next steps

Was this article helpful?
How can we improve it?