GoHighLevel Snapshots: Create, Load & Update (2026)
GoHighLevel Snapshots: Create, Load & Update (2026)
By Dr Priya Jaganathan, GoHighLevel Certified Admin · HL Growth Partner, Australia · Updated 12 August 2026 · 8 min read
GoHighLevel snapshots are reusable templates of a sub-account's assets — workflows, funnels, pipelines, custom fields and more — that you create once in the agency view and load into any new client account in minutes. That is the short answer. The longer answer — the one that decides whether your agency makes money on delivery — is about what a snapshot does not carry, and what happens when you push an updated snapshot onto a live client.
I have loaded well past two hundred snapshots across trades, allied health and franchise accounts here in Australia. The mechanics take four minutes to learn. The governance — naming, versioning, staging, knowing which assets silently duplicate on a refresh — is where almost every agency I audit is losing time. This guide covers create, load and update in the order you will actually use them, plus the gaps you must close manually on every Australian sub-account.
What a GoHighLevel snapshot actually is
A snapshot is a point-in-time copy of selected asset groups from one sub-account, stored at agency level, that can be deployed into other sub-accounts. It is not a live link — once loaded, the copy in the client account is entirely independent of the source.
The asset groups that travel include workflows and their triggers, funnels and websites, pipelines and stages, custom fields, custom values, calendars, forms and surveys, email and SMS templates, campaigns, tags, trigger links, and membership products. You are copying the structure of a working account, not the account itself — which is also why a snapshot is not a backup. Restoring one deleted workflow from a five-month-old snapshot drags back every other stale asset in the bundle.
How to create a snapshot in GoHighLevel
From the agency view, go to Account Snapshots, then Create New Snapshot. Choose the source sub-account, name it, and select which asset groups to include. Cherry-pick rather than taking everything: a bloated snapshot loads slowly and drags in half-finished experiments nobody remembers building.
Build from a clean source, never from a live client
The biggest quality problem I see is snapshots taken from live client accounts. You inherit their naming quirks, abandoned test workflows and hard-coded phone numbers. Maintain a dedicated master build sub-account that no client ever touches. Every change goes there first, gets tested there, and only then becomes a snapshot version.
Naming and versioning conventions
Use a convention that sorts sensibly and tells you three things at a glance: niche, maturity, date. I use TRADES-CORE-v3.2-2026-08. Niche prefix, CORE or overlay name, semantic version, year-month. Major bumps for structural change, minor for tweaks. When someone asks "which version is Bathurst Plumbing on?", the answer should be one line in a spreadsheet, not an archaeology project.
Keep a change log alongside it: version, date, what changed, which sub-accounts received it. Ten minutes a quarter, saves entire afternoons. A proper GoHighLevel tech stack audit of an inherited agency starts by reconstructing exactly this map.
How to load a snapshot onto a sub-account
There are two moments you can load. The first is at sub-account creation: as you add a new account in the agency view, select a snapshot from the dropdown and it deploys during provisioning. This is the cleanest path and your default.
The second is loading into an existing sub-account, from the snapshot's actions menu or from sub-account settings. Understand what that does: it is a merge, not a replacement. Snapshot assets are added alongside whatever is already there. If the account already has a workflow named "New Lead — Speed to Lead" and your snapshot contains one too, you end up with two, both live, both firing.
Load vs refresh: the distinction that matters
A plain load adds assets. A refresh (push update) tries to update assets from that snapshot lineage already in the target account. Refresh overwrites changes made locally since the last push — that tuned wait step, that reworded SMS — and duplicates assets wherever the link between snapshot and local asset has been broken by a rename or rebuild.
My rule: never refresh straight onto a paying client. Load the new version into a staging sub-account, diff it against what the client currently has, then decide whether to push or hand-apply three specific changes. Nine times out of ten, hand-applying is faster and safer.
Expect a queue, and check the result
Loads are asynchronous and a large snapshot can take half an hour. The "finished" notification is not proof everything landed. Spot-check: open two or three workflows, check pipeline stage order, and confirm calendars carried availability rather than defaulting to blank.
What does not travel in a snapshot
A snapshot copies configuration, not connections and not data. Everything below is done per sub-account, by hand, every time.
| Asset | Travels in snapshot? | What you must do manually |
|---|---|---|
| Workflows, triggers, campaigns | Yes | Re-check hard-coded links; publish anything that loads in draft |
| Funnels, websites, forms, surveys | Yes | Reconnect domain, swap branding, re-map form fields to live calendars |
| Pipelines, custom fields, custom values, tags | Yes | Populate custom values with the client's real details |
| Calendars | Structure only | Reconnect each user's Google or Outlook calendar; confirm availability |
| Contacts and conversation history | No | Import via CSV; migrate history separately if at all |
| Phone numbers / LeadConnector provisioning | No | Purchase or port numbers per sub-account |
| A2P 10DLC brand and campaign registration | No | Register per sub-account; allow days to weeks |
| Mailgun or email sending domain | No | Add domain, publish SPF, DKIM and DMARC records, verify |
| Payment gateways (Stripe, PayPal) | No | Connect the client's account; re-test a live transaction |
| Integrations and OAuth (Google, Facebook, Xero) | No | Reauthorise in the client's logins, not yours |
| Media library files | Partially / unreliably | Re-upload brand assets; check image links inside funnels |
| Users, roles and permissions | No | Invite users; set permission scopes per account |
| Domains and SSL | No | Point DNS, add the domain, wait for SSL issue |
| Saved reports and dashboards | No / inconsistent | Rebuild after the first fortnight of live data |
Two deserve extra attention for Australian agencies. Number provisioning and A2P 10DLC registration happen per sub-account — promise a go-live date without allowing for registration lead time and you will miss it. Registration does not travel, but your compliance wording does: bake ACMA-compliant opt-out language, sender identification and a functional unsubscribe into every SMS template in the snapshot, so no build ever ships without them.
Custom values: the localisation layer
The trick to a snapshot that deploys in under an hour is to build it entirely generic and push every client-specific string into custom values. No business name typed into an email body, no booking URL pasted into a workflow SMS. Instead: {{custom_values.business_name}}, {{custom_values.booking_link}}, {{custom_values.sender_id}}, {{custom_values.service_area}}.
Onboarding then becomes a single screen: open Settings → Custom Values, fill in fifteen fields from the intake form, done. Every funnel, email and SMS localises at once. Start with the mechanics of GoHighLevel custom values before you build anything else — retrofitting them into a mature snapshot is miserable work.
Keep a values checklist in the onboarding flow
Make the values list a checklist item, with a QA pass that searches published funnels for leftover placeholder text — a missed value shows up in the client's first campaign as "Book with {{custom_values.business_name}}". Our GoHighLevel client onboarding checklist sequences this against the DNS and A2P tasks that run on their own clocks.
Updating and sharing snapshots
To update a snapshot, make your changes in the master build sub-account, then either create a new snapshot version or update the existing one from that source. I prefer creating a new version and retiring the old one: it preserves an audit trail and stops anyone deploying a half-finished edit.
Sharing links and protecting your IP
HighLevel snapshots can be shared with other agencies via a share link, one-time or unlimited use, with an optional expiry. What you cannot control is what the recipient does once it lands. An unlocked snapshot hands over every workflow you have refined over years, in a form they can re-snapshot and resell. Use one-time links with a short expiry, share the minimum asset groups needed, and keep genuinely differentiated automation out of anything that leaves your agency. Pair that with tight GoHighLevel roles and permissions so sub-account users cannot export what you built for them.
Governance for 20+ sub-accounts
The model that scales is master plus overlays. One CORE snapshot holds everything universal: lead capture, speed-to-lead, no-show recovery, review requests, the base pipeline, the standard custom value set. Thin niche overlays carry only what is specific — a quoting funnel for trades, an intake form for allied health. Load CORE first, then the overlay, and you maintain one asset set instead of five diverging copies.
Review quarterly: walk the change log, retire anything unused, confirm every SMS template still carries current opt-out wording, and check whether new platform features have made a workflow redundant. The official HighLevel help documentation is worth a scan each cycle, and the HighLevel pricing page sets out where unlimited sub-accounts and SaaS features sit.
The delivery margin maths
Hand-building a competent sub-account — pipeline, six workflows, a booking funnel, templates, reporting — runs 12 to 18 hours. At $120/hr internal cost that is $1,440 to $2,160 of labour before the first strategy call. From a mature snapshot with a custom values layer, the same build takes 45 to 90 minutes plus the manual items (numbers, DNS, A2P, gateway): call it three hours including QA, about $360 against $1,800. That is roughly $1,440 of margin recovered per onboarding, close to $29,000 across twenty clients a year, and it is what makes productised delivery viable — the premise behind GoHighLevel SaaS Mode setup and pricing.
Common mistakes to avoid
- Refreshing a snapshot onto live client accounts. The number one cause of duplicated workflows and overwritten customisation. Stage the new version, diff it, then hand-apply targeted changes rather than pushing wholesale.
- Taking snapshots from a live client sub-account. You inherit their test data, their broken triggers and their hard-coded details. Maintain a clean master build account that no client can touch.
- Hard-coding client details instead of using custom values. Every business name, phone number and booking link typed directly into a template is a manual edit on every future deployment, and one you will eventually forget.
- Assuming A2P registration, numbers or DNS came across. They never do. Build these into the project plan as items with external lead times, not as five-minute tasks on go-live day.
- No versioning or change log. Without
NICHE-TYPE-vX.X-YYYY-MMnaming and a record of who received what, you cannot tell which client is on which build, and troubleshooting becomes guesswork. - Sharing unlocked snapshots with unlimited-use links. Your entire automation library walks out the door with no expiry and no way to recall it. Use one-time links, short expiry and the minimum asset groups, and treat a "load completed" notification as a prompt to QA rather than proof the build is ready to hand over.
If you want a snapshot library your team can deploy in under an hour, book a strategy call with the HL Growth Partner team.
Frequently asked questions
Do GoHighLevel snapshots include contacts and conversation history?
No. Snapshots copy configuration and assets only — workflows, funnels, pipelines, custom fields, templates and similar. Contacts, opportunities and conversation history stay in the source account. Migrate contacts by CSV import into the new sub-account after the snapshot has loaded, and map custom fields carefully so data lands in the right place.
What happens if I load a snapshot onto an account that already has one?
It merges. Assets from the new snapshot are added on top of what is already there rather than replacing it, so you can end up with duplicate workflows, funnels and pipelines all live at once. Load onto a staging sub-account first to see exactly what arrives, then decide whether to deploy or hand-apply individual changes.
Can I update a snapshot and push the changes to existing clients?
Yes, via a refresh or push update, but it carries real risk. Refreshing can overwrite customisation your team or the client made in the sub-account, and can duplicate assets where the link between snapshot and local asset has been broken by renaming or rebuilding. For live accounts, targeted manual updates are almost always safer.
Does a snapshot carry A2P 10DLC registration and phone numbers?
No. Number provisioning, A2P brand and campaign registration, Mailgun sending domains, payment gateways and OAuth integrations all have to be set up per sub-account. Only the templates and workflows that use them travel. Plan for A2P approval lead times separately from your build schedule.
How many snapshots should an agency maintain?
Fewer than you think. One core snapshot covering universal automation, plus two to four thin niche overlays, is enough for most agencies running twenty or more sub-accounts. Maintaining five near-identical full snapshots means five places to fix every bug. Review the set quarterly and retire anything that has not been deployed in six months.
