The snapshot moves what you built, not what the account accumulated

Snapshots are the reason agencies can onboard a client in a day instead of a fortnight, and they are the reason some client accounts go live half-configured.

Both come from the same property. A snapshot copies the structure of an account, not its contents. That distinction is documented clearly by HighLevel, and it is still the single most common source of surprise on deployment day, because “copy my account” sounds like it means the whole account.

What actually transfers

Per HighLevel’s snapshots documentation, a snapshot carries the things you configured:

• Workflows and triggers
• Funnels and websites
• Pipelines and their stages
• Calendars, as structure
• Forms and surveys
• Email and SMS templates
• Custom field and custom value definitions
• Tags and trigger links

That is a genuine head start, and for a repeatable service offering it is most of the build.

What does not

Everything the source account accumulated, and everything that required a credential.

Contacts and their history. Names, numbers, email addresses, conversation threads, call logs, appointments. None of it moves. This is correct behaviour, you would rarely want one client’s contact database appearing in another’s account, but it means a snapshot is not a backup and should never be treated as one.

Payment connections. Stripe and any other payment processor must be reconnected in the destination account. The workflow that references a payment step arrives intact and pointed at nothing.

API keys and third-party integrations. Google, Outlook, calendar connections, and anything wired through an API. The snapshot brings the structure that expects the integration, not the authorisation that makes it work.

Reputation data. Reviews and their history stay with the account that earned them.

The principle underneath all of it: a snapshot moves configuration, not state and not credentials.

The failure that is easy to miss

The exclusions above are visible. Something is obviously missing, somebody reconnects it.

The dangerous ones are the items that arrive looking complete and are not:

Custom values arrive empty or wrong. A workflow referencing a business name, a booking link or a phone number will happily send with the source account’s value or a blank. Nothing errors. The client’s first automated text goes out with somebody else’s business name in it.

Workflows may arrive inactive. Activation state is worth checking rather than assuming, because a deployed snapshot that looks correct and is not running produces the quietest possible failure.

Workflow portability has known limits. Copying workflows between accounts and having them travel inside a snapshot is a standing feature request on HighLevel’s own ideas portal, which is a fair signal that behaviour here has edges. Verify rather than assume, particularly on anything built recently.

The post-deploy checklist

Run this on every new sub-account before it touches a real lead. HighLevel’s own guide to creating a sub-account from a snapshot covers the mechanics; this is the part that follows.

1. Custom values. Every one, populated with this client’s details. This is the top of the list because it is the most common live embarrassment.
2. Payment connection. Reconnect Stripe. Run a test transaction if anything sells.
3. Integrations. Calendar, email sending, and anything external. Authorise each and confirm with a real action rather than a green tick.
4. Phone and messaging. Numbers provisioned, and A2P 10DLC registered for this account. A2P registration does not transfer and has an external review period, so it belongs at the start of onboarding rather than the end.
5. Domains. Funnel domains and email authentication for the new account.
6. Workflow activation state. Check each one is on, and that its triggers reference fields that exist here.
7. Calendars. Structure transfers, availability and connected accounts do not.
8. Send one real test through the primary journey, as a real contact, and read what arrives.

Step eight catches what the other seven miss. It is also the one that gets skipped when a launch is late.

What this means for how you use snapshots

A snapshot is a template, not a clone. That reframing settles most of the arguments about them.

It means a snapshot is an excellent foundation for a repeatable offering and a poor substitute for onboarding, because the parts it cannot carry, credentials, data and client-specific values, are exactly the parts that make an account that client’s. Budget for the configuration pass rather than treating deployment as the finish line.

It also means a snapshot is not a migration. Moving a live account with its contacts, history and pipeline positions intact is a different piece of work with a different risk profile.

If you are deciding between a snapshot foundation and a build from scratch, that trade-off is covered here.