GoHighLevel Snapshots: How to Deploy, Update & Manage Client Sub-Accounts (2026)

If you run a GoHighLevel agency, snapshots are the single biggest lever you have for delivering client sub-accounts quickly and keeping them consistent over time. A snapshot is a saved blueprint of an account's configuration — workflows, pipelines, calendars, custom fields, tags, email and SMS templates, funnels and more — that you can load into a brand-new sub-account in a couple of clicks. Done well, snapshots turn a multi-day manual build into a repeatable, predictable process you can hand to a team member.

The trouble is that most agencies treat snapshots as a one-off export and never revisit how they deploy, update or version them. That works until you have twenty sub-accounts on slightly different builds and a client asks why their workflow behaves differently to the demo. This guide walks through creating a snapshot, loading it into a new sub-account, pushing updates to existing accounts, what does and doesn't carry across, and how to manage versions once you are operating at scale.

What a GoHighLevel snapshot actually is

A snapshot lives at the agency level. From your agency view you can build a snapshot from an existing sub-account or from scratch, then store it in your library to reuse. When you load a snapshot into a sub-account, GoHighLevel copies the assets defined in that snapshot into the target location. The original sub-account the snapshot was built from is never altered — the snapshot is a copy, not a live link.

This matters because it shapes your whole workflow. A snapshot is a point-in-time capture. If you improve a workflow in your master build account after exporting, that improvement does not magically appear in the snapshot or in accounts already created from it. You have to deliberately re-capture and re-push. Treat your snapshot as a product you maintain, not a folder you forget.

Creating a snapshot from your master account

The cleanest approach is to keep one dedicated "master" sub-account that you never use for live client work. Build and test everything there — workflows, triggers, pipelines, calendars, custom fields and tags — then create your snapshot from that account. Building in a sandbox keeps real client data out of your blueprint and gives you a stable source of truth.

When you create the snapshot, GoHighLevel lets you select which assets to include. Be deliberate: include the workflows, pipelines, calendars, custom fields, tags and templates that every client needs, and leave out anything client-specific. Name the snapshot with a version number so future-you knows exactly what is in it — for example "Trades Core v2.3" rather than just "Trades".

Loading a snapshot into a new sub-account

When you create a new sub-account, GoHighLevel offers to load a snapshot during setup, or you can use "Load Snapshot" afterwards from the agency view. On a fresh, empty sub-account this is straightforward: the assets copy in, workflows arrive in draft or published state depending on your snapshot, and you then configure the client-specific pieces — business details, phone numbers, integrations, calendar availability and team members.

This is the backbone of any onboarding process. If you are running a productised offer, pairing snapshots with a structured intake makes delivery fast and repeatable. Our SaaS Mode onboarding system shows how to combine automatic snapshot loading with onboarding forms so a new client is essentially live the moment they sign up.

Niche snapshots versus a generic build

A generic snapshot rarely survives contact with a real client. The pipeline stages, automations and reminder cadences that work for a plumbing business are not what a dental practice needs. We maintain separate niche builds for exactly this reason — for example a cleaners & trades snapshot with quote-to-job workflows, and a dental & medical snapshot with recall and reactivation sequences. Niche snapshots reduce the post-load configuration work and make your demo feel tailored.

Pushing updates to existing sub-accounts

This is where most agencies get nervous, and rightly so. GoHighLevel lets you push or re-load a snapshot onto a sub-account that already has data and configuration. When you do, you are updating an existing account rather than building a blank one, and the platform applies the snapshot's assets on top of what is already there. Understanding the overwrite behaviour before you click is essential.

When you load a snapshot to update an existing sub-account, you can choose how asset conflicts are handled. The two practical outcomes are: assets that exist only in the snapshot get added, and assets that match existing ones can either be overwritten with the snapshot version or left alone. If you push an updated workflow, the snapshot version can replace the live one — which is exactly what you want for fixing a bug across all clients, and exactly what you don't want if a client has customised that workflow.

The safe way to push updates at scale

Never push a fresh snapshot to every client at once on a Friday afternoon. Pick one or two low-risk sub-accounts, push the update, and verify the workflows, triggers, custom fields and pipelines behaved as expected. Check that nothing client-specific was overwritten. Only once you have confirmed the behaviour on test accounts do you roll the update out more broadly. Always document what changed in each snapshot version so you can explain any client-facing difference.

What does and doesn't carry across

The most common support tickets come from misunderstanding the boundary between configuration and data. Snapshots carry your build — the structure and automation — but they do not carry contacts, conversation history or live activity. Here is a practical reference for what typically transfers when you load or push a snapshot.

Managing snapshot versions at scale

Once you have more than a handful of sub-accounts, version discipline is the difference between a tidy operation and chaos. Keep a simple register that records each snapshot name, its version number, the date it was captured, what changed since the previous version, and which sub-accounts have received it. When you refresh a snapshot on update, log the push. This register is what lets a team member answer "which build is this client on?" without guessing.

Adopt a clear naming convention and stick to it. Increment the version every time you re-capture from your master account. Retire old snapshots rather than deleting them, so you always have a record of what a given client received. If you maintain niche builds, version each one independently — your trades snapshot and your dental snapshot will evolve at different rates and should not share a version number.

Common mistakes to avoid

• Building snapshots from a live client account, so client-specific data and quirks leak into your blueprint.
• Pushing an updated snapshot to every sub-account at once without testing on one or two low-risk accounts first.
• Assuming an overwrite is harmless and wiping out a workflow a client had customised for their own behaviour.
• Forgetting that workflows often load as drafts, then wondering why automations never fired.
• Leaving snapshots unversioned, so nobody can tell which build a given sub-account is running.
• Expecting contacts, conversations or integrations to carry across and panicking when they don't.

If you want your GoHighLevel snapshots built and maintained so client sub-accounts stay consistent, book a strategy call with the HL Growth Partner team.

Book Your Strategy Call →

Frequently asked questions

Does loading a snapshot overwrite existing data in a sub-account?

Loading a snapshot copies in configuration assets such as workflows, pipelines, custom fields and templates. It does not touch your contacts or conversation history. However, when you push a snapshot to update an existing sub-account, matching assets can be overwritten with the snapshot version depending on the conflict settings you choose — so review the overwrite behaviour before you push, especially if a client has customised anything.

Can I update existing sub-accounts after I improve my master build?

Yes. Re-capture the snapshot from your master account with a new version number, then load it onto the existing sub-accounts you want to update. Test the push on one or two low-risk accounts first to confirm the workflows, triggers and pipelines behave as expected, then roll it out more broadly while logging each push in your version register.

Why did my workflows not run after loading a snapshot?

Workflows frequently arrive in draft state when a snapshot is loaded. Until you publish them, their triggers will not fire. After loading any snapshot, go through every workflow, confirm the triggers and actions are correct for that client, and publish each one. This single check resolves the majority of "the automation isn't working" tickets.

Do contacts and integrations carry across in a snapshot?

No. Snapshots are configuration blueprints, not data exports. Contacts, conversation history, connected phone numbers, payment integrations and calendar connections all stay with the original account and must be set up fresh in each live sub-account. Plan your onboarding so these client-specific connections are configured after the snapshot loads.

Should I use one generic snapshot or separate niche snapshots?

Separate niche snapshots almost always deliver better results. A trades business and a dental practice need different pipelines, reminder cadences and automations, so a generic build creates extra configuration work after every load. Maintaining tailored snapshots per industry reduces post-load setup, makes your demos feel relevant, and lets each build evolve at its own pace with its own version history.