#GTMTips: Change Management With Workspaces

A while ago, the Google Tag Manager team published one of my favorite feature releases in the history of GTM: Workspaces. I was so thrilled by this release that I went ahead and published a guide on how to implement and leverage this new feature.

Workspaces is a very comprehensive feature in Google Tag Manager. This is because it changed the entire underlying data model. We no longer work directly with a single container draft. Instead, our work is done in a cordoned section of the container, protected from changes made to other workspaces until such a time that we choose to sync the latest container version to our workspace, or vice versa.

This #GTMTips article is short and simple: it’s a reminder and a nudge to leverage workspaces efficiently.

Tip 52: Use Workspaces To Keep Track Of Change

First of all, if workspaces are completely alien to you as a concept, please take a look at my Workspaces Guide. It’s long and probably quite confusing (as my guides typically are), but it should get you up to speed with this enterprise-friendly feature.

In a nutshell, workspaces provides you the opportunity to work on multiple container drafts at the same time. Once the feature set is complete in a single workspace, you can Create a Version or Publish the workspace, so that it becomes the new Latest Container Version. After the Latest Container Version is updated, all existing workspaces will be alerted of this change, and you will then need to synchronize these new changes into all the other workspaces.

If you’re using the free version of Google Tag Manager, you have three workspaces that you can use concurrently. In Google Tag Manager 360, you have an unlimited number of workspaces at your disposal. This article mainly targets the former group, since necessity is the mother of innovation. Nevertheless, even if you have access to GTM 360 you should consider utilizing workspaces in such a manner that best relieves friction in your Google Tag Manager process.

What follows are some practices that I have found very useful when working with workspaces.

1. Use workspaces for feature updates

This might seem self-evident, but when workspaces was first released, a common reaction was to use them to isolate a part of the container for some team, and another part of the container for another team.

Workspaces isn’t a user management feature - it’s change management through-and-through. When you publish or create a version of your changes, the underlying workspace is deleted when the new version is created. This means that the feature doesn’t really lend itself for consistent use within a team.

Nothing’s stopping you from reserving one of the three workspaces to one team, another for some other team, and a third one for generic, incremental changes (see the next tip). However, you should be aware that the feature itself has no built-in functionality to support user management in that way, so you’ll have to make sure to use a naming convention “Team Name - Workspace Name”, for example, to make it clear that the workspace is for a specific team.

2. Always have one workspace available for small, incremental changes

One of the main benefits of workspaces is that you can finally commit your small change to a single tag and publish it without having to worry about taking a bunch of unfinished work with the update into the live container.

For this reason and for the sake of agility, it is important to always have one workspace available for small, incremental changes.

Once you’ve done the change, you can either Create a Version or directly Publish the workspace, depending on what the appropriate workflow is in your organization.

The best part about this is that even when you publish your small, incremental change, any other workspace in the container doesn’t need to merge the changes you made until they are ready to do so. This deferred synchronization is another great thing about the feature.

3. Defer synchronization until you are ready to do so

When someone has updated the Latest Container Version by publishing their changes, you’ll see a small banner in the bottom of the screen as well as the “UPDATE” button in the Overview Dashboard (see image above).

This means that there are changes to the Latest Container Version that should be merged with your workspace before you can Publish or Create a Version of your workspace.

It’s good to know that you don’t have to do this until you’re ready to merge!. The note is there to remind you that you need to merge before you’re done with your workspace, but you might want to audit the changes before you sync them with your workspace.

To check what changes would be merged, click the “UPDATE” button in the Overview Dashboard. A new fly-out will appear, where you’ll see all the versions that have been created after your workspace was detached from the version branch. You can click these versions to see what changes have been done, and thus you can prepare your workspace to accommodate these disruptions if necessary.

Remember that even if there are conflicts, Google Tag Manager will warn you of these and force you to resolve them before the sync is complete. Even so, it’s still a good idea to briefly check each update to see if there’s something you should consider in your workspace, conflicts or not.

4. Name your workspaces clearly

I’m not usually one to froth at the mouth over naming conventions, but with workspaces I might consider an exception. By naming the workspace, you are actually giving a name to the version you’ll inevitably create from the workspace, too. Yes, you can rename the container version at any time, but it cuts one step out of the workflow if you name the workspace with the future version in mind.

Consider naming the workspace with a compact but comprehensive description of what the feature increment that you’re doing is. Typically, if you find it difficult to come up with a name that covers all the changes introduced in the workspace, it means that you’re doing too much in a single go, and you might consider rethinking your approach in the future. I always prefer small, incremental changes over big, whopping, world-altering feature blasts. Small updates also make it easier to keep all other workspaces in sync.

Remember that naming versions is purely for your own benefit. If you ever need to roll back, or if you need to find a specific version, the version name (and sometimes the description) is pretty much all you have to work with. Because of this, it’s important to name every single version you create so that anyone glancing at the version name would have even just a cursory idea of what was updated in that version.

Summary

It would be silly to say “I hope you’re using workspaces already”, since everyone using Google Tag Manager is, by default, using workspaces already.

It might be a bummer to some to only have three workspaces available in the free version of GTM. However, apart from initial implementation or larger, migration-level projects, three workspaces should always be enough for the type of iterative, agile change management that Google Tag Manager necessitates, at least in my experience.