Workspaces

A Google Tag Manager workspace allows you to create multiple sets of changes for your container. Team members can work on changes in separate workspaces to independently develop their own tag configurations. This feature helps with version control by enabling you to revert changes to a previous workspace configuration, and helps prevent teammates from inadvertently publishing someone else's unfinished changes.

Every time you make changes to a container, you are making those changes in a workspace. Every container creates a default workspace. You can add up to two additional workspaces for regular accounts, and can create an unlimited number of workspaces for Tag Manager 360 accounts.

When to create a new workspace

A workspace in Tag Manager is a place to work on a set of changes that will become a version. Create a new workspace when you want to develop and test tag configurations separately from your main production tag configurations, or when you have multiple users that work on different 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

Use the Workspaces page to create a new workspace, switch to a different workspace, or remove an existing workspace.

To create a new workspace:

• In the left navigation, click the Current Workspace menu.
• In the upper right corner of the Workspaces page, click Add Add.
• Enter a name and description for the new workspace. The workspace name and description may later become the version name and version description, so establish a meaningful naming scheme that reflects the objectives of the workspace. For example: "New Floodlights for Q1", "Updated Google Analytics for Q2", etc.
• Click Save.

To switch to a different workspace:

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

To remove a workspace:

• In the left navigation, click the Default Workspace menu.
• Click Info Information to the right of the workspace you want to delete.
• 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: A default workspace, and two custom workspaces.

Update workspaces

When you have multiple workspaces in use, any given workspace may become out of date with changes that were made elsewhere in the container. To update a workspace:

• When you attempt to publish a workspace and 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."
• Click Update Workspace to view a list of unmerged versions.
• In the list of unmerged versions, click an entry to view what changes were made in that version.
• Click Update to merge in the changes.

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

Resolve conflicts

The Workspace Overview page displays a “Conflict found” message if any conflicts are identified. Select Resolve conflicts to bring up the conflict resolution tool.

You can resolve them one at a time. The configuration of the latest synced version is shown on the left, and the configuration 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: A modification has been made between the latest synced version and the current workspace.
• Red: A modification in the latest synced version is not present in the current workspace.
• Green: A modification in 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. You can use Resolve All to ignore all the changes from the latest synced version. Once all conflicts are resolved, save your changes. Repeat this process for any other 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 for workspace management

Keep changes small: 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 workspaces to group common changes: If you have an agency that works on both Google Analytics and Floodlight tags, use two workspaces to keep the configurations separate. This allows you to publish tags in a controlled order, and will make your version history clearer.

Use workspaces to manage teams: Have each team or individuals work in separate workspaces. Additionally, each team or individual may have more than one workspace for different sets of changes.

Use consistent, descriptive naming practices: When a container is published or a version is saved, enter a Version Name and Description that will make it easy to know what changes were made. For example:

• Version name: "GA page view tag initial launch"
• Description: "Launch the Google Analytics page view tag on example.com."

Use workspaces to test a configuration: Workspaces can be used to test changes without the risk of someone else accidentally publishing your work. You can use a workspace as a sandbox to try out changes to your container configuration. If you choose not to publish the changes in that workspace, you can save the workspace for later reference or delete it.