A snapshot push is meant to ship improvements out to your linked sub-accounts — but the same mechanism can quietly roll back edits someone made inside one of those accounts. Here is how snapshot updates actually behave, what they can and cannot clobber, and how to move a specific workflow without putting anything live at risk.
If you build in GoHighLevel at agency scale, snapshots are how you keep clients on a shared system: you link each sub-account to a master snapshot, then push updates out as you refine the build. It is efficient, right up until the day a push lands and a workflow someone customised for one client looks the way it did weeks ago. The fear is real, and the mechanism behind it is specific. Knowing exactly when a snapshot update can overwrite a workflow — and when it cannot — is the difference between shipping updates confidently and dreading every push.
A snapshot is a whole-account template: a point-in-time bundle of a sub-account's workflows, pipelines, custom fields, calendars, funnels and settings. When you create a new sub-account from a snapshot, that account can stay linked to it. Linking is what makes updates possible — it lets you push changes from the master snapshot out to every account built from it, so an improvement you make once reaches the whole fleet.
A push only touches accounts that are linked to that specific snapshot; an unlinked account is never affected by it. When you do push, GoHighLevel lets you choose which asset categories go out and how they are applied. That choice is the whole story here. Used carefully, a push is a clean way to roll out one new automation across many clients. Used without reading the options, it is how edits disappear.
The risk comes from how a push matches assets. A snapshot update does not blindly dump everything; it looks at what already exists in the linked account and decides, per category, whether to add only new assets or to override matching ones with the snapshot's version. When override is in play and a workflow in the account matches one in the snapshot, the incoming version replaces it — and any edits made directly in that sub-account since it was created go with it.
That is the scenario agencies rightly dread. A client asked for a tweak to their nurture sequence, someone made it in the sub-account, and then a routine snapshot push — intended to ship a completely different new workflow — rolled that account's copy back to the master version. There is no per-workflow diff warning before it happens and no obvious changelog afterwards; the workflow simply reads the way the snapshot says it should, not the way the account last left it.
It is worth being precise, because not everything is at risk. A push configured to add only leaves existing assets untouched and simply drops in what is new. Workflows you built locally in a sub-account — ones that never existed in the snapshot and so match nothing in it — are generally left alone either way. Your contacts, conversations and the data a client has accumulated live outside the snapshot entirely and are never carried by a push.
What gets clobbered is the overlap: a workflow that exists in both the snapshot and the linked account, when the push is set to override that category. That is the collision point. And one honest caveat applies whichever way you move automations — sending infrastructure is per-account. The sending domain, from-address, phone number and A2P registration never travel with a workflow in a snapshot or anywhere else, so those connections always belong to the destination account on their own terms.
The deeper issue is that a snapshot is the wrong instrument when the job is one or a few workflows into accounts that are already live. It is all-or-nothing and account-wide, so you cannot ship a single automation through it without accepting its push rules for everything else in that category. A per-workflow tool sidesteps that completely.
ExportGHL Workflows works at the level of the individual automation. You save a workflow from the source account to a private cloud library — capturing the full build: every trigger, every action in order, waits, branches and settings — then deploy it into a destination account when you need it. Save a workflow once and deploy it into each account that needs it, as a repeatable move from the library rather than a fleet-wide broadcast. Cross-account remap matches references — pipelines, stages, tags, users, custom fields, calendars and templates — by name in the destination and rewrites the ids, so steps resolve instead of opening blank.
This is the part that directly answers the overwrite fear. Every deploy lands as a new workflow in the destination, sitting alongside whatever is already there. It does not match against and replace an existing automation the way a snapshot push can. Nothing a client depends on is touched unless you make a separate, deliberate choice to update a specific workflow — and even then it is one workflow you singled out, not a category-wide override applied silently.
Remap adds a second layer of safety. When it cannot confidently match a reference by name, it does not guess and it does not publish a broken step. It flags what it could not map and imports the workflow as a draft, so you review something that is wired up and paused, not something live with a hole in it. Between those two behaviours — new by default, draft when unsure — there is no path where a deploy quietly rolls back work you did not ask it to touch.
In practice, the clean split is this: use snapshots for what they are built for — standing up new, empty sub-accounts from a known-good baseline — and be deliberate about linked pushes, reviewing the add-versus-override setting every time. For targeted changes into accounts that are already live, move the specific workflow with save and deploy instead, so each change is intentional and nothing else is disturbed.
A cloud library makes that repeatable: refine a workflow once, save it, and deploy it into each client as you are ready, keeping a clean reusable workflow template library rather than re-snapshotting everything. If you are weighing the two approaches more broadly, see snapshots vs workflow export, and for the step-by-step of a single move, read how to copy a workflow between accounts. Moving your first workflow is free, with no card.
Deploy a workflow as a new automation — never an overwrite unless you choose one. Your first move is free, no card.
Start free
ExportGHL