How to create a GoHighLevel snapshot

Making a snapshot is trivial: pick a sub-account, save it, done. Making a snapshot that still makes sense on its twentieth import is a different job, and it is almost entirely about decisions you take before you build anything.

Build in a clean room

Never create a snapshot from a live client account. It carries their naming, their half-finished experiments and the workflow somebody disabled in March for a reason nobody wrote down.

Build in a dedicated sub-account that exists only to be the master. Nothing real ever runs in it, which means you can leave a workflow half-built overnight without messaging anyone.

Decide the naming convention first

This is the highest-leverage twenty minutes in the whole build. Pick a scheme and never deviate.

We use Area - Trigger - Outcome, so a workflow reads as Intake - Form submitted - Book inspection and a funnel reads as Acquisition - Free inspection. It sorts alphabetically into useful groups, and six months later somebody who has never seen the account can find the thing that is misbehaving.

What matters is less which convention you choose and more that a stranger can predict the name of an asset they have not yet found.

Put every variable in a custom value

This is the difference between a snapshot and a template.

Anything that changes per client belongs in a custom value: business name, phone, address, service area, booking link, pricing, offer amounts, seasonal dates, sender name, review link. Then reference the custom value everywhere, in every email, SMS, funnel headline and workflow condition.

Done properly, installing the snapshot for a new client becomes editing one screen instead of hunting through thirty-eight message templates for the town name.

Two habits that pay off:

• Prefix them, for example biz_name, biz_phone, offer_intro_price. They group together and are obvious in a merge field.
• Fill them with an obvious placeholder, not a real business. SET_BUSINESS_NAME in a live message is embarrassing but visible. A leftover real client name is embarrassing and invisible.

Know what does not travel

Build around these rather than discovering them at import time.

• Integrations and credentials. Stripe, Google, Facebook, phone numbers, A2P registration. None of it transfers.
• Media library files. Images referenced by funnel pages frequently need re-uploading, so keep them few and keep a copy.
• Contacts, conversations, opportunities, appointments. Structure only, always.
• Anything referencing a specific user. Assign tasks and calendars to roles you recreate, not to a person who only exists in the master account.

Test it the only way that counts

Import your own snapshot into a second, empty sub-account. Not once, at the end. Do it at the halfway point too, because a structural problem found at fifty percent costs an hour and the same problem found at the end costs a day.

Then walk the import as if you were the buyer. Every workflow: does it have a trigger that exists here, filters that reference fields that came across, and an exit condition. Every funnel: does the form on it feed the workflow you think it does. Every calendar: is it attached to the funnel step.

Keep the second sub-account. It is your regression test for every future version.

Write the change list

The single thing that separates a professional snapshot from a hobby one is a document that says: here are the eleven values you must change, here is the order to do it in, and here is what each one affects.

If nobody has written that list, nobody has installed the snapshot twice, and the buyer is about to become your quality assurance.

Sharing it

From agency view you can share a snapshot directly with another agency, or generate a share link. Links can carry an expiry and a use limit, which is what you want if you are selling access rather than giving it away.

Two practical notes. First, a share link is claimed by an agency account, so a buyer who clicks it from a sub-account login gets a permission error and emails you; say this in the delivery email. Second, decide your update policy before the first sale, because “do I get updates” is the second question every buyer asks and the first one they get annoyed about.

Version two without breaking version one

Never overwrite a snapshot that clients are running on. Create a new one, name it with a version, and keep the old one available.

Then publish a change list: what is new, what changed, and what is safe to apply to a live account. Sub-accounts on version one keep working. Clients who want the new workflow get the new workflow, applied by hand, with their customisation intact. Anything else eventually means telling somebody you overwrote their build.