GTM Ultimate Stack
Read the Review & apply preview before anything is written
Understand the dry-run preview: what each outcome means in every container, how to fix skipped items, and how the workspace options decide where your changes land.
The preview always comes first
However large the batch, Review & apply starts the same way. ODDVX runs a dry run of every staged change against every container involved and shows you the result. The dialog says it plainly: Nothing has been written yet. This is exactly what Apply will do. Nothing is published.
The dry run doesn't even create a workspace. When you press Apply, ODDVX sends the identical batch you previewed. The only difference is that this time it is written.
Four steps: you press Review & apply, a dry run checks every container and writes nothing, you read the preview, and Apply stages the identical batch.
Read it container by container
At the top, a row of totals counts the batch, for example 6 will create · 2 renames · 1 skipped. Below that, each container has its own block:
- the container and the number of changes for it;
- the workspace it will use: would create workspace "…" or reuses workspace "…";
- one line per change, with an outcome badge and the item's name.
Collapse the containers you have checked. In a big batch, work through it in the order you plan to publish.
A review dialog with totals for will create, renames and skipped, and blocks for three containers listing their changes.
What each outcome means
Every line in the preview carries one of these badges. Read the badge before the item name: it tells you what Apply will actually do.
| Badge | Meaning |
|---|---|
| would create | A new tag, trigger or variable will be added to the workspace |
| would copy | A copy will be added, with its triggers and variables if you chose that |
| reused | The target already had a trigger or variable with this name; it is used as is |
| would rename | The display name changes from the old to the new; nothing else does |
| would pause / would activate | The tag's paused state changes |
| would delete | The item is removed from the workspace |
| installs template / enables {{…}} | Added so the new item works: a Community Template, or a built-in variable |
| skipped: reason | Not done in this container. The reason says why |
| error: message | Only after Apply: GTM itself refused the change and gave this reason |
A two-column list of outcome badges with one-line meanings.
Fix skipped items before you apply
A skipped item isn't an error. It means ODDVX couldn't do that change safely in that container. The common reasons, and what to do about each:
| Reason | What to do |
|---|---|
| trigger "X" not found in this container | Add the trigger to the same batch for this container, or create it, then re-run |
| variable {{X}} not found | Copy with Include its triggers and variables, or add the variable to the batch |
| a tag named "X" already exists | Copy a single item under a New name, or rename the target's existing tag first |
| the container is at its workspace limit | Choose Use its Default Workspace, or free a workspace in GTM and re-run |
A review dialog where three containers show a skipped change with its reason and an arrow to the fix.
Choose where the changes land
Below the list, Target workspace decides where Apply writes:
- New workspace per container (the default) uses a workspace under the name in Workspace name, for example ODDVX cleanup 2026-10-05, in each container. Give it a name that will mean something in GTM, like Lead rollout Oct. If a container already has a workspace with that name, the changes are added to it rather than to a new one.
- Default Workspace writes straight into the workspace most teams publish from. Use it only when you mean to.
Editing the name refreshes the preview, and Apply waits until it has, so you never apply against a preview you haven't seen.
When a container is at its workspace limit
GTM limits how many workspaces a standard container can have. For a container that is full, If a container is at the workspace limit gives you two choices: Skip & report (nothing is done there, and it is listed so you can come back) or Use its Default Workspace. See Workspaces, publishing and recovery.
A review dialog with the target workspace options: new workspace per container with the name Lead rollout Oct typed in, or the Default Workspace.
After Apply
When Apply finishes, the dialog closes and the results fold back into the table:
- created and copied rows lose their pending marks and become normal rows;
- renamed, paused and activated rows show their new state;
- deleted rows leave the table;
- anything that didn't go through keeps a note with its reason (skipped: … or error: …), so you can see what is left to do.
Your changes now sit in the workspaces. The next step, publishing, is yours: Workspaces, publishing and recovery.
An inventory table after Apply: two new tags marked created, one marked skipped because the trigger was not found, and a renamed tag.
ODDVX for Windows
Build once. Stage it in every brand.
Start free on one GTM account. Premium adds several accounts in one run, exports and scheduled reports.