Use workspaces to manage multiple sets of tag changes.

Workspaces enable you to create multiple and differing sets of changes to your container. Different users can work on changes in separate workspaces to independently develop tag configurations. This feature helps with version control by enabling you to roll back changes to a given workspace, and helps prevent teammates from inadvertently publishing unfinished changes being worked on by another group.

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 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.

Create a workspace when  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 recorded with the version. The workspace is then removed. The default workspace will be recreated after it is versioned or published.

Manage workspaces

Create a new workspace, switch to a different workspace, or remove an existing workspace from the Manage Workspaces page.

To create a new workspace:

  1. In the left navigation, click the Current Workspace menu.
  2. In the upper right corner of the Manage Workspaces page, click Add Add.
  3. Enter a name and description for the new workspace. 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.
  4. Click Save.

To switch to a different workspace:

  1. In the left navigation, click the Default Workspace menu.
  2. on the Manage Workspaces page, select a workspace from the list.

Tip: If you have a long list of workspaces, you can narrow it down by clicking the search icon in the upper right corner and entering a term.

To remove an existing workspace:

  1. In the left navigation, click the Default Workspace menu.
  2. Click Info Information to the right of the workspace you want to delete.
  3. Click More Actions More in the upper right corner and select Delete.

Tag Manager 360 customers can create an unlimited number of workspaces. All other users may have up to three concurrent workspaces, consisting of a default workspace and two custom workspaces.

Update workspaces

When working with multiple workspaces, any given workspace may become out of date with changes happening elsewhere in the container.

To update a workspace:

  1. When publishing a workspace where changes from another version have been found, Tag Manager will show a notification that states "This workspace is out of date. It will be updated automatically if you proceed." 
  2. Click UPDATE WORKSPACE to view a list of unmerged versions.
  3. Optional: In the list of unmerged versions, click an entry to view what changes were made in that version.
  4. Click UPDATE to merge in the changes.

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

Resolve conflicts

The Workspace Overview page displays a “Conflict found” message if any conflicts were identified. Select Resolve conflicts and the conflict resolution tool appears.  

For each entity in your workspace where a conflict was found (i.e. each tag, trigger, variable, etc.), you can 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, decide whether to ignore the change from the latest synced version or copy the change from the latest synced version. Select Resolve All to ignore all the changes from the latest synced version. Once all of the conflicts have been resolved, you can save the entity. Repeat this process for any other entities with conflicts.

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

Best practices

Create a workspace for each set of changes that are related and that 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, use at least two workspaces to keep the configurations separate. This allows 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 changes to  your site or app. If you choose not to publish them, you can save the workspace for later reference, or delete it.

Next steps

Was this article helpful?
How can we improve it?