Guides / Snapshots vs backups
Snapshots vs real workflow backups
A Snapshot answers “how do I set up the next client?” A backup answers “what did this workflow look like before someone edited it?” Agencies need both, and confusing one for the other is how automations get quietly broken.
What a Snapshot actually is
A Snapshot is a packaged template of an entire sub-account: workflows, funnels, pipelines, calendars, custom fields, templates. You take it from the agency dashboard and load it into another sub-account, fresh or existing, choosing which assets come across.
That makes it the right tool for exactly one job: deploying a proven setup to the next client. Two-day onboarding becomes two hours.
What a Snapshot can’t do
It’s not readable
A Snapshot file is a deployment artifact. You can’t open it and read what a workflow does, and you can’t compare last month’s snapshot to this month’s to see what changed. For history and auditing it might as well not exist.
Restoring from it overwrites, with no undo
Loading a Snapshot into a live account lets you pick individual assets and decide, conflict by conflict, whether to override the existing one or skip it. Override replaces what is there, and HighLevel says that can’t be undone through the load. A restore from a Snapshot is a one-way door.
It needs agency access
Snapshots live at the agency level. If you’re a contractor or team member working inside someone else’s agency, they’re out of reach entirely.
It is only as recent as the last one
A Snapshot holds the account as it was when it was taken. Unless someone took one just before the change that broke things, the version you need isn’t in it.
What a real backup gives you
A backup is a dated, readable record of what a workflow said at a point in time. When something breaks or a client asks “did the follow-up sequence always send three emails?”, you answer from the record instead of memory. The practical test: can you diff two versions? With a Snapshot, no. With JSON exports, yes, that’s the default.
The side-by-side
- Deploying to new clients: Snapshot. Nothing else comes close.
- Surviving edits: backup. Before any meaningful change to a live workflow.
- Auditing inherited accounts: backup with reference checking: dead tags, renamed pipelines, triggers pointing at nothing.
- Handovers: transfer the sub-account itself, and export the workflows first, so both agencies can see what was handed over.
How we’d sequence them
Build the setup once → Snapshot it for deployment. Then, before every meaningful edit to a live client account, export the workflows you’re about to touch as dated JSON. Monthly bulk exports for accounts nobody’s watching. Ten seconds per workflow, free tier covers it, and it’s the difference between “something changed” and knowing exactly what.
Workflows are one part of an account. For contacts, opportunities, form submissions and the rest, see how to back up a GoHighLevel account, part by part.
FAQ
Does a GoHighLevel Snapshot back up my workflows?
Not in a way you can read back. A Snapshot packages account structure as a deployable template. You can load individual assets from it, but you can’t open it to see what a workflow said, or compare two to see what changed.
How often should I back up GHL workflows?
Before every meaningful edit, and on a schedule for accounts you don’t touch often; monthly is a common cadence for client accounts.
Inherited an account nobody can explain any more? A GoHighLevel automation audit is the version of this where someone else reads all of it.