Workspaces, publishing and recovery for multi-brand changes

One named workspace in every container

By default, Apply writes into a workspace with the same name in every container in the batch. That one name is your handle on the whole change. Search for it in GTM and you find the rollout in every brand. Put it in your change log and the next person can trace what happened.

If a container already has a workspace with that name, the changes are added to it. That is useful for building a rollout across several sessions, and it is what makes resuming work (see below). Choose names that describe the change, for example Lead rollout Oct or Orphan cleanup Q4, rather than a generic default.

Mind GTM's workspace limit

A standard GTM container allows only a few workspaces at once, counting the Default Workspace. In containers where several people work, that limit is easy to hit, and someone else's unfinished workspace may be using a slot.

When a container is full, the review offers two choices:

• Skip & report: nothing is done in that container, and it is listed so you can come back later. This is the safe default.
• Use its Default Workspace: the change goes into the workspace the team publishes from, alongside whatever else is there. Only choose this if you have agreed it with the container's owner.

ODDVX can't delete workspaces. If old ones are clogging a container, remove them in GTM after checking with whoever created them.

Publishing stays with you

ODDVX stops at the workspace. Publishing is a human decision, and in multi-brand work it is where your judgement matters most. For each container:

1. Open the workspace in GTM and look at its changes. Check that it holds only what you reviewed, with nothing left over from someone else.
2. Use Preview to test the journeys the change affects.
3. Publish, with a version name and description that match the workspace name and your change log.

Go brand by brand. Start with the brand where a problem would be easiest to spot and cheapest to fix, then work outwards. If something surprises you in the first brand, you can stop before it reaches the rest.

Resume an interrupted batch

A large batch can stop part-way: a lost connection, the computer going to sleep, or a temporary limit on GTM's side. You don't need to work out by hand what landed. Run the same batch again with the same workspace name.

Before creating anything, ODDVX checks whether the target workspace already has an item with that name. Items that landed the first time come back as skipped: … already exists, and only the missing ones are created. The preview shows you exactly which is which before you apply the second time.

Roll back, before and after publishing

How you undo a change depends on how far it has gone:

• Before Apply: Discard all clears every staged change; Revert undoes the selected rows.
• After Apply, before publishing: nothing has reached visitors. Delete the workspace in GTM, or remove the individual changes inside it.
• After publishing: use GTM's version history to go back to the previous version. To stop one tag quickly, pause it in ODDVX, apply, and publish that.

ODDVX keeps no separate backup of deleted items. After a delete is published, GTM's version history is the record.

Verify and record

After publishing, extract the brands again and filter for what you changed, for example Name equals: GA4 - Event - generate_lead. Every brand should show the item, in use. Anything missing is either a skipped container you meant to come back to, or a workspace that hasn't been published yet.

Record the workspace name, the containers, the reviewer and the test you ran in your team's change log, so the next person can trace what happened.

Keep going

• Read the Review & apply preview
• Swap a vendor tag across brands in one batch
• Schedule a recurring orphan report