Skip to content
New: GA4 dashboards, server-side conversions to every ad platform, Consent Mode v2 generation, and publish approvals.See what shipped
TagEasy

Documentation

Setup, platform installs, monitoring, and the API. Written to be followed, not skimmed.

Publish approvals & GTM environments

By default an editor can publish a website's GTM workspace to the live container from the Publish to GTM panel. Change control adds two things on top: a publish policy that requires someone else to approve before anything goes live, and GTM environments so a version can be tried on a staging site first. Both are available on the Business plan and above. Existing requests can always be viewed and resolved, whatever the plan.

Publish policies

  • Publish directly (default) — editors publish themselves, exactly as before.
  • Admin approval — a publish request must be approved by an organisation admin or owner other than the person who raised it. Self-approval is what the policy exists to prevent.
  • Client approval — intended for agencies. The client approves through a signed link sent by email; nobody needs a TagEasy login. An admin can override an unresponsive client, and the override is recorded in the activity log.

Auto-publish keeps syncing the workspace under every policy — a workspace change fires nothing on the site. Only the final publish is gated.

Step 1 — Set the publish policy

On the website's Settings tab, choose Admin approval or Client approval under Publish policy and save. Only an organisation admin or owner can change it. Changing the policy does not touch requests that are already open; each decision checks the policy at the time it is made.

Step 2 — Request a publish

On the Events › GTM sub-tab, the Publish button becomes Request publish. Give the request a title and a description of why the change is being made, and submit. TagEasy syncs the workspace, takes a snapshot of the container (it appears in the Versions panel as a request version), diffs it against the last published version, and emails every admin and owner — and, under client approval, the client contact. A Slack, Discord or Teams webhook on the organisation gets the same message.

Several requests can be open at once; the panel warns when they are, because each one snapshots the whole container and the later one will include the earlier one's changes.

Step 3 — Review the request

A reviewer opens the request from the email or from the Requests list. The review shows who raised it, the description, the entity-by-entity diff against the last published version (the same comparison the Versions panel renders, down to the changed fields), and the discussion so far. They click Approve or Request changes, optionally with a note; anyone on the website can comment.

Under client approval the client decides from the signed link. The approval page shows the same summary without any login, takes their name and an optional note, and accepts one decision; after that the link stays readable but cannot be used to decide again. The link is emailed when the request opens; Copy client approval link in the review drawer mints a fresh one (the emailed link is replaced).

The requester is emailed when a decision is made. A request that was sent back can be approved later once the discussion settles; published and cancelled are final.

Step 4 — Publish the approved request

Once approved, the requester or an admin clicks Publish on the request. TagEasy syncs the workspace, creates the container version and publishes it live — the same path the direct button uses — records the published version, and closes the request. If the container's tags, triggers, variables or destinations changed since the snapshot was reviewed, the publish is refused and a new request is needed, so an approval never covers changes nobody looked at.

GTM environments and staging

A GTM environment serves a chosen container version under its own install snippet, so a staging or preview site can run tags that are not live yet. The Environmentssection of the publish panel lists the container's environments (Live,Latest and any you created) with the version each one serves.

  • Create staging environment adds a user environment named TagEasy Staging to the container.
  • Publish latest to Staging creates a container version from the workspace (or uses the newest version when nothing is pending) and points the staging environment at it. The live container is not touched.
  • Copy snippet gives you the environment's install code: the normal gtm.js snippet with gtm_auth, gtm_preview and gtm_cookies_win parameters. Install it on the staging site in place of the live snippet.

Environment publishes are logged as gtm.environment-published. Versions created for staging show up in the GTM container versions list, so the one the client tried can be the one that goes live.

What is recorded

Every step writes to the activity log: publish-request.created, publish-request.approved, publish-request.changes-requested, publish-request.cancelled, publish-request.published and website.publish-policy-changed. Decisions carry who decided, whether it came through the client link, and whether it was an admin override.

See also GTM tags & variables for what the workspace contains, and the agency tier for managing client organisations.