GTM containers, workspaces, versions and publishing

#01Account, container, workspace

Account. Usually one per company. User permissions are managed here.

Container. One per digital property type you manage. Typical marketing setup: one Web container for the marketing site, maybe another for the app webview, and later a Server container. Container IDs look like GTM-ABC1234.

Workspace. A draft sandbox inside the container. Google Tag Manager creates a Default Workspace. You can add more so two people edit without stomping each other. Changes in a workspace are not live until you submit and publish.

According to Google Tag Manager Help on publishing, when you click Submit you can Publish and Create Version or Create Version without publishing. Publishing makes the configuration active for the chosen environment.

#02Versions are your undo button

Every publish records a version. Versions list who published, when, and the name and description you typed. Good descriptions look like this:

• 2026-11-05 Add generate_lead GA4 event for demo form
• 2026-11-05 Fix Consent Mode defaults for EEA
• 2026-11-05 Rollback: Meta Pixel double-firing on thank-you

Bad descriptions look like update, fixes or are left blank. Six months later, blank descriptions make audits painful (lesson 19).

To recover from a bad publish:

1. Open Versions.
2. Select a known-good version.
3. Use Publish from the Actions menu, or Set as latest version then publish, depending on the UI options shown.
4. Verify in Preview on production that the restored behaviour is correct.

Our view: treat a production publish like a site deploy. If you would not ship website copy without a proofread, do not publish a container without Preview.

#03Workspaces without the drama

Use multiple workspaces when:

• Two people need to edit at the same time.
• A project will take days (for example ecommerce data layer) and should not block hotfixes.
• An agency needs an isolated area you can review before merge.

Workspace hygiene:

• Keep Default Workspace for small fixes, or keep it clean and work in named workspaces.
• Sync the workspace with the latest version before you start a big change.
• Publish or abandon workspaces; don't leave five half-finished ones.
• If GTM reports conflicts, resolve them deliberately; don't click through blindly.

Google Marketing Platform customers may also see Request Approval on submit. If your organisation uses approvals, budget time for a reviewer who understands tags, not only brand.

#04Environments

Environments let you publish different versions to different places. Common pattern:

Each custom environment can have its own install snippet or a shareable preview link. When you publish, choose the environment. Publishing only to Staging never updates Live.

If you only have a production site and no staging, you can still work safely: use Preview, publish during low traffic, and keep version notes excellent. Environments become valuable once staging exists.

#05Publishing checklist marketers actually use

Before Publish and Create Version:

1. Preview on the real template you changed (thank-you page, checkout, not only the homepage).
2. Confirm the right tags fire, and the wrong ones don't.
3. Check consent behaviour if you touched consent (lesson 12).
4. Read the Workspace Changes list on the Submit screen.
5. Write a version name and a two-line description.
6. Tell whoever owns GA4/Ads that new events may appear (and whether they're marked as key events yet).

After publish:

1. Hard-refresh the live page and run Tag Assistant or a spot check.
2. Watch Realtime / DebugView in GA4 for a few minutes if you changed analytics tags.
3. Keep the previous version's ID in your notes until you're confident.

#06Permissions worth getting right

GTM roles (exact labels can vary slightly by account type) generally separate view, edit, approve and publish. Marketing ops often needs publish rights on web containers. Agencies often should get edit on a workspace but not publish to Live. Server containers may sit with engineering.

Write down who can publish. "Everyone with the login" is how accidental publishes happen.

#07Worked example: Ledgerline's first version discipline

Ledgerline is a fictional accounts-payable software company. Details are illustrative.

Ledgerline created one web container and invited the marketing lead (publish), a contractor (edit) and the founder (admin). They agreed: contractor works in a workspace named project-webinar-events, marketing lead reviews in Preview, only marketing lead publishes to Live. Version names always start with the date.

The first week the contractor almost published from their own user after receiving Admin by mistake. Permissions were corrected. The near-miss convinced them the rule mattered more than the tool.

Walkthrough

1. Open your container. Note whether you are in Default Workspace or another workspace.
2. Make a trivial change: add a folder named _sandbox (folders are covered more in lesson 18) or rename a unused tag's note.
3. Click Submit. Choose Create Version only (don't publish yet) if you are on production and the change is pointless. Name it clearly.
4. Open Versions and confirm the version exists.
5. If this is a sandbox container, publish to Live with a clear description.
6. Create a second workspace named project-practice. Switch between workspaces and notice drafts are separate.

#08Approvals and agency workflows

If you use Google Marketing Platform-style approvals, treat the reviewer as a measurement owner, not a rubber stamp. The reviewer should open Preview, not only read the version text. Agencies should never be the sole Live publisher for a brand-spend account unless contractually and operationally intended.

A clean agency pattern:

1. Agency workspace agency-YYYYMM-project.
2. Agency submits version without publishing (or requests approval).
3. Internal ops runs Preview on staging + production sample pages.
4. Internal ops publishes with their own version description referencing the agency ticket.

#09Environment gotchas

• Publishing to Staging does not update Live. People forget and "test" on production traffic by accident.
• Custom environment snippets differ from the Live snippet. Installing the Staging snippet on production is a classic outage.
• Share Preview links expire mentally even when they still work — do not use them as permanent QA bookmarks for months.

#10Rollback drill (do this once on a sandbox)

1. Publish version A with a visible unused tag (for example a GA4 event rollback_drill on a hidden page).
2. Publish version B that pauses that tag.
3. Roll back to A via Versions.
4. Confirm the tag returns.

Teams that have never rolled back waste critical minutes during a real incident.

#11Try it yourself

Write a one-page "publish policy" for your team: who can publish, required Preview steps, version naming format, and how to roll back. Share it in the same place you keep UTM rules.

#12Quick quiz

1. Does Submit always change the live site?

Answer: No. You can create a version without publishing. Only publish updates the chosen environment.

2. Why use a separate workspace for a two-week ecommerce project?

Answer: So hotfixes can still ship from another workspace without mixing unfinished ecommerce tags into production publishes.

3. What is the fastest recovery from a bad publish?

Answer: Publish a previous known-good version from the Versions list, then verify in Preview/Tag Assistant.

#13What should you check before the next lesson?

• You can find Versions and read a version description.
• You know who in your company can publish.
• You have a version naming convention written down.

Previous: How GTM works for marketers. Next: Install GTM and the Google tag. Or return to the GTM for Marketers track.

#14Common questions

Do I need multiple workspaces? One Default Workspace is enough for a solo marketer. Use more when two people edit at once or you want a long-running project isolated.

Can I undo a bad publish? Yes. Open Versions, choose an earlier version, and publish it.

What are environments for? Named publish targets such as Dev and Live, so staging can run a different version than production.