GoHighLevel Snapshots: Build, Load & Update (2026)
GoHighLevel Snapshots: Build, Load & Update (2026)
By Dr Priya Jaganathan, GoHighLevel Certified Admin · HL Growth Partner, Australia · Updated 21 August 2026 · 8 min read
GoHighLevel snapshots are a template of a sub-account's structure — the workflows, funnels, pipelines, calendars, custom fields, custom values, tags and email templates you have built — packaged so you can drop the same build into a new sub-account in minutes. They copy configuration, not data, and that distinction is where most agencies come unstuck. A snapshot will happily rebuild a 40-step nurture sequence in a fresh location, but it will not bring across contacts, conversation history, phone numbers, A2P registration, connected Google or Stripe accounts, or the media files your funnels point at. The structure lands; the plumbing does not.
The second thing that burns agencies is the ongoing link. You can load a snapshot once, or attach the sub-account so future updates push down automatically. Agencies tick the second option without thinking, make client-specific changes inside the live sub-account, then push a refresh six months later and overwrite the lot. Workflows revert. Custom values duplicate. Calendars detach from staff. None of that is a bug — it is what a push is designed to do — but it costs a weekend of rebuild work and an awkward client call. This guide covers building a master worth cloning, loading and pushing properly, and updating without detonating live builds.
What GoHighLevel snapshots actually are
A snapshot is a saved copy of a sub-account's asset configuration, taken from Agency view and stored at agency level. It is not a backup and it is not versioned for you — it is a frozen picture of that sub-account at that moment. Snapshots sit under Agency Settings → Snapshots, where you can create, rename, share via link, load into a sub-account, or attach them for future pushes. In SaaS Mode they are also applied automatically at signup, which is why the master must be clean before you switch billing on.
Snapshots are structure, not state
The mental model that keeps people out of trouble: a snapshot carries what you built, not what happened. Anything a client or their leads generated — contacts, opportunities, SMS threads, call recordings, bookings — stays behind. So does anything a provider owns, because Twilio numbers, Mailgun domains and Stripe keys are credentials tied to a specific location ID.
What a snapshot carries vs what it does not
| Asset | Carried in a snapshot? | What to do instead |
|---|---|---|
| Workflows, triggers and campaign steps | Yes — structure and step logic | Re-map any step referencing a user, calendar or number |
| Funnels, websites, forms and surveys | Yes — pages and structure | Redo domain mapping and re-point hard-coded links |
| Pipelines and stages | Yes — empty, stages intact | Opportunities do not follow; import via CSV or API |
| Custom fields and custom values | Yes — values are the duplication risk on refresh | Lock naming before the first snapshot; never rename in a child account |
| Tags and email templates | Yes | Audit branding before snapshotting, not after loading |
| Calendars | Structure yes, staff assignment no | Reassign team members and reconnect sync manually |
| Contacts, conversations, notes, appointments | No | CSV import contacts; history cannot be moved |
| Phone numbers and LC Phone/Twilio config | No | Buy or port numbers per sub-account; they bill per location |
| A2P 10DLC brand and campaign registration | No | Register per sub-account with that client's business details |
| Mailgun sending domain | No | Connect a domain and set DNS before email workflows go live |
| Integrations and OAuth (Google, Stripe, Facebook) | No | Reconnect under Settings → Integrations after load |
| Media library files | No — links may point back to source storage | Host assets on a stable URL, or re-upload and re-link per account |
| Payment credentials and products | Keys no; products may partially transfer | Reconnect Stripe and verify price IDs before testing checkout |
Treat the right-hand column as your post-load checklist. Nine out of ten "the snapshot is broken" tickets are one of those non-transferable items sitting unconnected while a workflow tries to fire through it.
Build a clean master sub-account first
Do not snapshot a client account. Ever. They accumulate one-off fixes, half-finished tests, a workflow called "Copy of Copy of Nurture v2", and custom fields named after a single campaign. Snapshot that and you export the mess into every future build.
Instead, create a dedicated sub-account — MASTER – Core Build v3 — that exists only to be cloned. Nothing live runs in it: no real contacts, no client integrations, no purchased numbers. Build only the assets you genuinely reuse — intake funnel, speed-to-lead workflow, missed-call text-back, reactivation campaign, standard pipeline, calendar shell, review request sequence — test each with a dummy contact, then delete the test data before you snapshot. If you ship under your own brand, sort your white label setup first, so every template and login link is already branded.
Naming conventions that survive contact with reality
Naming is boring and it is the highest-leverage thing you will do. The convention we use across agency portfolios:
- Workflows:
[Category] – [Purpose] – v[Number], e.g.LEAD – Speed to Lead SMS – v2. Prefixes group alphabetically, which is how the list sorts. - Custom fields: prefix by object and never abbreviate inconsistently —
contact_lead_source, notLead Srcin one place andSourceelsewhere. - Custom values: prefix with
cv_and keep them generic —cv_business_name,cv_booking_link,cv_office_phone. - Snapshots:
[Vertical] – [Build] – v[Number] – [YYYY-MM], e.g.Dental – Core – v4 – 2026-08. Never overwrite a name; increment it.
Custom values matter most, because they are the layer that lets one build serve many clients. A workflow referencing {{custom_values.cv_booking_link}} instead of a hard-coded URL turns onboarding into a form-fill.
Creating the snapshot and loading it into a sub-account
From Agency view, go to Settings → Snapshots → Create New Snapshot, choose the source sub-account, name it using your convention, and select which asset types to include. Excluding assets you do not want in every build is far easier at creation than cleaning up afterwards.
To load it, either select the snapshot while creating a new sub-account, or open an existing one and use Settings → Manage Snapshots. Loading into an existing location is additive, but overlapping names create duplicates, so do not stack two similar snapshots.
Once the load finishes, work the right-hand column of the table above: reconnect integrations, buy or port the number, register A2P, connect the sending domain, reassign calendars, fill in every custom value, then test one workflow end to end with a real mobile and inbox. A GoHighLevel implementation checklist earns its keep here.
One-off load vs an ongoing push link
This is the fork in the road. A one-off load drops the assets in and walks away — the sub-account is independent from that moment. An ongoing link keeps it attached to the snapshot, so when you push an update the linked locations receive it, immediately or on a schedule.
Ongoing pushes suit a standardised SaaS product where every customer runs the same build. They are dangerous for done-for-you clients where each account has been tailored; use one-off loads there and accept that updates are manual. If you are running SaaS Mode pricing with plan-attached snapshots, the linked model is the point — but then you need discipline about never customising inside a customer's location.
Snapshot drift and version control
Drift is the gap between your master and what is running in the field. A client asks for a small change, someone edits the workflow in their sub-account, and that location now differs from the master and its 20 siblings. Six months on, no two accounts match. There is no native version history, so build it yourself:
- Keep one master sub-account per vertical and author every change there.
- Increment the snapshot name each time. Keep the previous two versions; delete the rest.
- Maintain a sheet: version, date, what changed, which sub-accounts received it, one-off or linked.
- Log client-specific deviations the day they are made. That list is your blast radius when you next push.
For franchise groups drift compounds fast, because head office expects consistency while each location wants exceptions. The pattern that works is covered in our guide to multi-location franchise setup: standard assets stay linked to the master snapshot, location-specific assets are built in each sub-account with a naming prefix that makes them obviously off-master.
What breaks when you push a refresh
A refresh push does not merge intelligently. Know these behaviours before you touch the button.
Workflows get overwritten
If a workflow in the sub-account shares an ID lineage with one in the snapshot, the push replaces it — client-specific edits included. Custom wait times, changed copy, added conditions: gone. Workflows built fresh in the sub-account usually survive, which is why bespoke work should be new assets, not edits.
Custom values duplicate
Rename a custom value in the master and push, and the sub-account often ends up with both keys. Workflows referencing the old one keep pulling the stale value while you are looking at the new one — the most common cause of "the SMS is sending the wrong booking link" tickets. Deprecate custom values; never rename them.
Other predictable casualties
Calendars lose staff assignments and availability overrides. Funnel pages revert to master copy, taking client-specific offers with them. Pipeline stages reorder or duplicate if names were changed locally. Trigger links and email templates get replaced. Nothing warns you, so you find out when a client does. If a push has gone wrong, our workflow troubleshooting guide covers tracing what fired.
A safe update procedure
Use this sequence every time. It costs an hour and saves weekends.
- Author in the master only. Never make the change directly in a client account.
- Test in the master. Run a dummy contact through and confirm every message, condition and wait behaves.
- Create a new versioned snapshot. New name, incremented, dated. Do not overwrite the previous one.
- Push to a staging sub-account first. Keep one throwaway location mirroring a typical client, then check custom values for duplicates, calendars for staff assignment, workflows for reverted copy.
- Check your deviation list. Any sub-account with client-specific edits is excluded from the bulk push and updated manually.
- Push in a small batch. Three to five sub-accounts, verify, then the rest.
- Notify clients of anything user-facing. Message copy, booking flow, form fields.
- Log it. Version, date, recipients, what changed, anything that broke.
Two references worth bookmarking: the official GoHighLevel help documentation for current snapshot behaviour, since the UI and push options change between releases, and the GoHighLevel pricing page for which tier covers unlimited sub-accounts and SaaS Mode. HighLevel snapshots carry no extra cost, but how many sub-accounts you can load them into depends on your plan.
Common mistakes to avoid
- Snapshotting a live client account. You inherit their test data, naming chaos and one-off fixes. Snapshot from a purpose-built master.
- Assuming contacts, numbers or A2P come across. They do not. Budget onboarding time for number provisioning, A2P registration and email domain setup every time.
- Linking every sub-account for pushes by default. Only link accounts you are willing to overwrite. Bespoke builds should be one-off loads.
- Renaming custom values in the master. That duplicates keys on push and leaves workflows quietly referencing the stale one. Deprecate instead.
- Overwriting the same snapshot name. With no version history you cannot roll back or say what a client is running. Increment and date every version.
- Pushing to the whole portfolio at once. Staging first, then three to five, then the rest. A bad push to 40 sub-accounts is a long week.
If you want your snapshot rebuilt as a clean, versioned master that you can push to new sub-accounts without breaking live client builds, book a strategy call with the HL Growth Partner team.
Frequently asked questions
Do GoHighLevel snapshots include contacts and conversation history?
No. Snapshots carry configuration only — workflows, funnels, pipelines, custom fields, tags, calendars and templates. Contacts, opportunities, message threads, call recordings and appointments stay in the source sub-account. Contacts can be moved by CSV; conversation history cannot be transferred between locations.
What is the difference between loading a snapshot and pushing an update?
A load is a one-time copy, after which the sub-account is independent. A push sends updates from a snapshot to sub-accounts linked to it, immediately or on a schedule. Pushes overwrite matching assets rather than merging, so linked accounts should never be customised locally.
Will pushing a snapshot refresh delete work I have done in a client sub-account?
It overwrites any asset that came from the snapshot originally — edited workflows and funnel pages revert to master copy, and calendars can lose staff assignments. Assets built fresh in the sub-account generally survive, so build client-specific work as new assets rather than edits.
Can I roll back a snapshot push if it goes wrong?
There is no native rollback. Your only recovery path is loading a previous version, which is why you keep the last two and never overwrite a snapshot name. Anything custom that got overwritten must be rebuilt by hand, so always test on a staging sub-account first.
Do I need a specific plan to use snapshots in SaaS Mode?
Snapshots are available on agency plans, but attaching one to a SaaS plan for automatic provisioning at signup requires the tier that includes SaaS Mode. Check the current pricing page, since tier inclusions change. Build discipline matters more than tier — a messy master provisioned automatically just scales the mess.
