Publishing, versions, and approvals

Publish containers

When you publish a container, Tag Manager will make your changes active for the environment specified. If you've added or edited tags, triggers, and variables in a workspace, you will need to publish those changes to make those changes operational on your website or mobile app.

To publish your current workspace:

• Click Submit at the top right hand side of the screen. The Submit Changes screen will appear, with options to publish the container and save a version of your container.
• Select Publish and Create Version if it is not already selected.
• Review the Workspace Changes section to see if your configuration appears as you expect.
• Enter a Version Name and Version Description.
• If you have Tag Manager configured to use multiple environments, use the Publish to Environment section to select which environment you'd like to publish to.
• Click Publish.

Versions

A version is a snapshot of a container configuration at a particular time. You can save the current state of a workspace as a version at any time. This enables you to revert your workspace back to a previous version if necessary.

Versions can make it easier to recover from mistakes. For example: 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.

Users with Approve access or higher can create versions. Every time a container is published, a version of that container is recorded.

To save the current workspace as a version before it is published:

• Click Submit. The Submit Changes screen will appear, with options to publish or save a version. (Google Marketing Platform customers will see an additional option to Request Approval.)
• Click Create Version.
• Enter a Version Name and Version Description.
• Click Create.

To publish a previously saved version of a container to the site:

• Click Versions.
• Click the desired version in the table.
• Click Action and then Publish.

Tag Manager maintains a publish history, so you can see when versions were live and who published them. To see the publish history, go to Versions and look for entries with a date in the Published column.

To replace the current container version with a previously saved version:

• Click Versions.
• Click the Actions menu next to the desired container version.
• Select Set as Latest Version.

This replaces the current container draft with the content of the selected container version. You may then make any additional modifications to the container draft, and publish your changes when ready.

To publish a specific version from the Versions screen: Identify the version you'd like to publish and then select Publish To... from the Actions menu.

When you publish or create 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 pageview tag on example.com.

Approvals

This feature is only available in Google Tag Manager 360, which is included in the Google Marketing Platform.

Containers owned by Tag Manager 360 accounts can add approvals to their workflow. Users with Edit access or higher will see an additional option to request approval to publish changes that they have made.

Request approval

To request approval for changes made to a workspace:

• Click Submit.
• Select Request Approval.
• Optional: Click Choose Approver to identify someone to review and approve your request.
• Optional: Use the Comment section to add a descriptive comment to help an approver understand the requested changes.
• Click Request.

If you are using a workspace that has a pending approval, you will see a banner that indicates the workspace is pending approval status. Click View Request to see the changes as they were requested.

Approve requests

The Approvals page will list all approval requests that have been submitted for a given container. These items will include requests to publish workspaces, approve External Account Links, and add tags pushed from Campaign Manager. When there are requests pending approval, the Approvals tab will have an indicator next to it:

• A blue circle means there are open requests that are either assigned to another user, or are available for anyone to review and approve.
• A red circle means there are open requests assigned specifically for you to review.

To review and approve or reject an approval request:

• Click the Approvals tab.
• Click the name of the entry to be approved.
• Review the details of the request.
• Optional: To assign a specific approver, click Choose Approver.
• Optional: To add comments to a request, click Add Comment.
• Click Approve to approve the request, Send Back to deny the request and have the original submitter make further edits, or Withdraw to cancel a request.

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.