Clean up orphaned triggers and variables across brands in one batch

Start from a reviewed candidate list

This guide assumes you already know what the usage verdicts mean and have checked your candidates with their owners. If not, start with Reading GTM usage verdicts. Orphaned means nothing references the item today. It doesn't mean nobody will miss it.

Work in rounds, triggers first. When you delete an orphaned trigger, any variables that only that trigger used become orphaned too. They won't show as orphaned until you publish and extract again. A typical cleanup looks like this:

1. Delete the orphaned triggers you have agreed to remove.
2. Publish each container, then extract again.
3. Review the variables that are newly orphaned.
4. Delete those in a second batch.

Filter to the orphans in every container

Extract the brands in scope (see Inventory every brand in one extract). Then:

1. Click the Orphaned tile, or choose Usage: Orphaned.
2. Click the Triggers tile, or set Entity: Triggers.
3. If you are cleaning one brand at a time, set Container. To see the same leftovers across every brand, leave it on all.

The same old trigger often turns up in several brands. Click - Old Banner copied years ago into every site is a common sight. Seeing them side by side is the point: you can agree the decision once and apply it everywhere.

Select what the filter shows, and only that

Use Select all shown to select exactly the rows the filter is showing. Then read the selection bar before doing anything else.

A selection is kept when you change the filter. If you selected rows under one filter and then changed it, some selected rows may now be hidden. The bar shows this as 6 selected of 4 shown (2 hidden by filter). Bulk actions apply to every selected row, hidden or not. Press Clear and select again if the hidden ones weren't meant to be included.

Untick any row you haven't agreed to delete. The goal is the smallest change that has been approved, not the largest one the filter allows.

Stage the deletions and check the pending list

Press Delete. Nothing is removed yet: each row is marked with a pending delete, and the bar at the bottom shows the count, for example 4 pending changes · 4 deletes · staged into a workspace, never published.

Turn on Pending only to see just the rows you have staged. This is the list your reviewer should see. If something shouldn't be there, select it and press Revert. Discard all clears every staged change.

Review per container, then confirm

Press Review & apply. ODDVX runs a dry run and lists every container, the workspace each change will go into, and every would delete line. Check the list against your approved candidates, container by container.

• Give the workspace a name that will mean something in GTM, for example Orphan cleanup Oct. The same name is used in every container.
• At 10 or more deletes, Apply stays locked until you type DELETE. That pause is there to make you read the list one more time.
• Apply re-sends exactly the batch you previewed.

For what each outcome means, see Read the Review & apply preview.

Publish each container and verify

Open each container's workspace in GTM. Check that it contains only your deletions and nothing from anyone else. Use preview mode on the journeys these triggers used to serve, then publish. ODDVX doesn't publish for you.

Then extract again. The Triggers count should drop by the number you deleted. Some variables will now read Orphaned where they used to read Only inactive users or In use: those were used only by the triggers you removed. They are your second round. Review them the same way, and don't delete them just because the first round went well.

Keep going

• Use case: make GTM cleanup a reviewed decision
• Reading GTM usage verdicts
• Workspaces, publishing and recovery