15 Sep 2016
GTM Workspaces
Reading time: 8 mins.

Google Tag Manager Updates (I): Workspaces

Change? I hate change!

Recently, and following a closed beta period, Google has published a new version of Tag Manager that includes a number of significant improvements, such as a total redesign of the management interface.

The main innovation, however, which has been announced with much fanfare, are Workspaces. This new feature promises to improve the way we work with GTM, particularly on those occasions when we do so concurrently, with various users or groups working on the same container.

1. What are Workspaces and what are they used for?

Short version: they allow us to work with various container drafts simultaneously, featuring individual tracking of changes, synchronization between versions and detection/resolution of conflicts.

Basically, it’s a step up from the system of drafts and versions that we’ve had until now.

La escena de hacking mas estupida de la historia, y mira que hay candidatas
Let’s both edit at the same time! What’s the worst that could happen?

Previously, for each container we had a draft, which comprised the container we were working on and contained a history of all the changes that had been made; and we had the versions, which comprised a list of “copies” of the container we were creating and were saved sequentially, whether on the basis of the current draft or that of earlier versions. We could publish, preview and restore any version at any time.

However, although this way of working was convenient when there was just one user, it could become problematic when a number of different users, departments or agencies had control over the container in question. Each change was applied simultaneously to the same draft, meaning there was no way to stop changes from overlapping with each other or the container being published at an inopportune moment, and it was generally impossible to carry out parallel development securely without coordination or restriction.

2. Workspaces = several simultaneous drafts

Now, however, for each container there are one or more Workspaces, and each of them functions as an independent draft.

In the GTM interface, when we open the “Container” tab it automatically changes to “Workspace”. If we’ve created more than one Workspace (there’s one already created by default, named – as you might expect – “Default Workspace”), then a panel appears in which we can specify the Workspace we wish to open, as shown below:

Workspaces list

Once we’ve opened it, it will become an editable draft.

From the same panel we can also choose to edit (click on the “Info” icon to the right of each option), delete (while editing, you can choose this option from the top menu next to the “Save” button) or create (click on the “+” button in the top right) new Workspaces.

NOTE: When a new Workspace is created, it’s always based on the most recently saved version of the container. This version is not necessarily the one that is currently published, or even the most up-to-date (for example, there may be unpublished changes in another Workspace).

We can return to this panel at any time by selecting the new option (shown below) in the left-hand menu:

Select GTM Workspace

From now on, we can work in our chosen Workspace like always, and publish the changes at any time. But what happens in the event of a conflict? What happens to the other Workspaces if we want to publish ours? And what happens to our Workspace if someone creates a new version of the container?

Well, that’s when the new synchronization function comes into play.

3. Publishing and synchronization

Every time the Publish (or Create Version) option is chosen in a Workspace, the following happens:

1) A new publishing interface is displayed:
Publishing panel

This new panel is much more than a simple confirmation dialogue. Among other things, it gives us a full summary of the changes made (plus the option to manage them individually – see below!) and a box where it tells us to identify the version to be created by adding a name and description, if we haven’t done so already. In fact, if we don’t identify it, it will give us another reminder prior to publication. Now there’s no excuse!

GTM container version description

2) Once the operation has been confirmed, a new version of the container is created (and published, if we’ve specified that option) based on the Workspace, and that Workspace is then automatically deleted, unless it’s the Default Workspace.

3) And now the magic happens: if there are other Workspaces, they are automatically notified that a new version has been created, along with a link to update the Workspace with the new changes:

Update workspace

If we close this notification, it will remain available – along with the link – on the Overview screen:

Workspace update in overview panel

Even if we ignore it, we can’t get rid of it, because when we go to publish, it’ll notify us again. And if we don’t update manually, it’ll do it automatically as part of the publication process.

Update now

In any case, once we’ve chosen to update the Workspace, a panel like the one below will appear:

Update GTM workspace

From here, we can review all of the versions (as there may be more than one) with which the current Workspace needs to be synchronized, and confirm by clicking on Update.

Normally, that’s the end of the process: the changes to each separate version are integrated into the Workspace and we can publish it or continue editing it. But what happens if there are still conflicts? If two versions or Workspaces have made parallel changes to the same tag, trigger or variable, which of them takes precedence?

Fortunately, the update process automatically detects and notifies us of these conflicts and gives us an opportunity to resolve them:
Conflict notification

If we click on Resolve (this option is also available in the Overview panel) or on a specific conflict, a new panel will open in which we can view and compare both versions, revise them and make a decision regarding each conflict. We can choose to prioritize one of the versions over the other or even combine them by taking changes from both.

Conflict resolution panel

We’ll take a closer look at this panel below.

4. Advanced change tracking

Although this change management feature is especially useful for resolving conflicts, its functionality doesn’t stop there. In fact, anywhere there’s a summary of the changes that have been made (e.g. in the Overview or Publish panels), we have the option to select each change individually and review it or reject it:
Abandon change

If we select the Abandon Change option, the change is undone, as if it had never been made in the first place.

If we select the View Change option, the same version-comparison panel as the one shown for conflicts will appear:

Conflict resolution

In both instances (conflicting versions, original vs. modified) the two versions are shown side by side, with each change individually highlighted: fields added in green, fields deleted in red, and fields modified in blue.

For each change, we can click on the central arrow and decide whether to Ignore them (i.e. stick with the version in our Workspace) or Copy them (i.e. overwrite the Workspace with the other version).

If we’ve accessed the conflict resolution panel, we also have the option to navigate between conflicts (by using the Previous/Next arrows) and Resolve All, which automatically applies the Ignore option to all of the changes (this also occurs when the Workspace is automatically updated as a result of publication).

Once all of the conflicts have been resolved, we can click on Apply or Save to confirm the changes.

5. Notes and references

Finally, there are a few other things we should point out regarding Workspaces:

Luego prendes fuego a la oficina, y con razon
Has anyone seen my AdWords tag? Anyone?
  • Currently, the number of simultaneous Workspaces is limited to three in the standard (i.e. free) version of GTM; however, this is not the case in Google Tag Manager 360 (the paid-for version included in the Google Analytics 360 suite). At present, this is the only difference between the free and premium versions of GTM… and we hope it remains that way for a while 😉
  • For now at least, the new layer of separation introduced by the Workspaces has not been extended to security. No Workspace-level permissions have been added: permissions remain at Container level and any user with the appropriate permissions can view, edit or publish any Workspace. But at least now, if someone starts messing around with something they shouldn’t, it’s easier than ever to detect it – and fix it! 🙂

And of course, the obligatory links:

In the next post we’ll give you the second part with all the other updates!