How a workspace works
A container starts with one default workspace. Creating another gives you a private copy of the container as it currently stands live, and every tag, trigger or variable you touch changes only that copy. Other people editing in their own workspaces see nothing of your work, and you see nothing of theirs.
When you publish, Tag Manager merges your workspace back into the container and creates a version from the result. If somebody else published while you were building, your workspace is now based on an older starting point and the interface asks you to update it. Where the same tag was edited on both sides, that update raises a conflict you must settle by hand, choosing which change survives.
A container may hold only a limited number of workspaces at once, and the limit is higher on the paid tier. Abandoned workspaces therefore have a real cost: they eventually stop the next person opening one.
Why workspaces matter
They make parallel work safe on a container that more than one person touches. On a typical project an agency may be adding remarketing tags in the same week a developer is repairing a form event and a freelancer is adding a heatmap script. Without separate workspaces, whoever publishes first publishes everybody’s half-finished work.
They also make a change reviewable. Because a workspace holds one person’s edits and nothing else, the change list attached to it is a clean statement of what that person did — far easier to check than a comparison of the whole container.
Common mistakes with workspaces
The most damaging is treating a workspace as long-term storage for work that never quite finishes. Left open for months, it drifts further from the live container with every publish somebody else makes, its conflicts multiply, and merging it becomes a job nobody volunteers for. Finish it or discard it.
The second is settling a conflict by keeping your own change without reading the other one. The conflict screen shows both, and the right answer is sometimes a third option that preserves both intentions. Clicking through it quickly deletes a colleague’s fix without anyone noticing.
How to work with them
Open a workspace for a single piece of work, name it after that work rather than after yourself, and close it within days by publishing or discarding. Update it before you start so it is built on the current live state, then update it again just before publishing in case anything moved while you were building.
On a container shared with outside suppliers, agree in advance who is allowed to publish. Workspaces keep the editing apart but cannot stop a rushed release, and the version history is the only place the damage shows afterwards. If you are setting a container up from scratch, settle workspace and permission rules alongside the rest of the tag management plan rather than after the first accident.