How to create a GoHighLevel snapshot

The mechanical part of creating a snapshot is five clicks in the agency view. Almost every guide stops there, which is why so many home-made snapshots load into a client account carrying the builder's own phone number, three workflows called "Copy of Copy of Nurture", and a funnel that references a domain the client does not own.

The clicks are below. So is the hour of preparation before them, which is the part that decides whether the snapshot is an asset or a liability.

Prepare the source sub-account first

A snapshot is a photograph. It captures whatever state the sub-account is in, including the mess. Clean it before you take the picture, not after.

Name everything as if a stranger will read it

Because one will — including you, in four months. A workflow called "Nurture" is useless in an account that will have several. Prefix every asset with the funnel or system it belongs to: "Roof-Inspection — Day 1 Email", "Roof-Inspection — No-Show Recovery". The prefix is what stops collisions when the snapshot loads into an account that already has assets.

Delete anything named "Copy of". If it was worth keeping it is worth naming.

Move every hard-coded string into a custom value

This is the single highest-value step, and it is the one that separates a professional snapshot from a personal backup. Business name, phone number, address, booking link, offer price, support email, opening hours, the sender name on emails — all of it should be a custom value that pages and messages reference, never typed into the content.

Do it properly and rebranding the whole system is editing a dozen fields on one screen. Skip it and every deployment is an afternoon of hunting through emails for a phone number.

Set the custom values to obvious placeholders

Not your details. Not "Business Name" either, which is easy to miss when it appears mid-sentence. Use something that cannot survive a review — "[[YOUR BUSINESS NAME]]" — so an unconfigured value is visibly wrong in a test submission rather than quietly plausible.

Remove your own test data and connections

Test contacts, test opportunities, your own calendar connection, any integration keyed to your account. Contacts do not travel in a snapshot, but calendar and integration configuration can leave references behind that produce confusing errors in the destination.

Decide the workflow publish state deliberately

Imported workflows arrive in draft in the destination account regardless — that is platform behaviour and it is the most common reason a freshly loaded snapshot "does not do anything". You cannot change it, so document it. If you are handing the snapshot to someone else, tell them which workflows to publish first and in what order, because publishing all of them at once is how a contact ends up in two sequences an hour apart.

Creating the snapshot

1. Switch to the agency view. Snapshots are created at agency level, not from inside a sub-account.
2. Open the account snapshot area and choose to create a new snapshot.
3. Select the source sub-account — the one you just cleaned.
4. Name it with a convention you will still understand later. Niche, purpose and version works: "Roofing — Inspection Funnel — v3". Version numbers matter more than they seem; you will make a v4.
5. Choose the assets to include. Take everything the system needs and nothing it does not — an unused funnel from an old test is dead weight that someone will later have to identify and delete.
6. Create it, and wait for it to finish packaging.

To share it, generate a share link from the snapshot. That link is the deliverable; there is no file. You can generate links with different permissions depending on whether the recipient should be able to re-share, which matters if the snapshot is a product rather than an internal tool.

Test it before you trust it

This is the step everyone skips and it is not optional. Create a brand new empty sub-account, load the snapshot into it, and configure it as if you were the customer, using only the documentation you wrote.

What you are looking for:

• Any placeholder still showing your details, or any obvious placeholder still showing after you have set every custom value you documented.
• Broken image references — media does not always travel, and a funnel with missing images is the first thing a buyer sees.
• Funnel step paths that still reference the source domain.
• Workflows whose triggers point at forms or calendars that did not come across under the same name.
• A full test submission: fill in the form with a real address and phone, walk every step, confirm the workflow fires once published, and check the notification.

Then delete the test sub-account. If you found nothing, you have a snapshot. If you found three things, you had a snapshot that would have produced three support conversations.

What makes a snapshot genuinely reusable

Reusability is not a feature you enable, it is a set of decisions taken during the build. Four of them do most of the work:

The scope row is the one most home-made snapshots fail. A snapshot of your whole working sub-account carries every experiment you ever ran. Build the system you intend to package in its own clean sub-account and snapshot that.

Versioning, and what to do when you improve it

A snapshot is a point in time. Improving the source sub-account does not update the copies already loaded elsewhere — there is no upgrade path, and anyone who tells you otherwise is describing something GoHighLevel does not do.

So keep the version in the name, keep a short changelog, and when you push a new version to an existing account, load it into a fresh sub-account first and migrate the pieces that changed. Loading v4 on top of v3 in a live account produces two of everything.

When to build one and when to buy one

Build one when the system is yours — a process specific to how you work, an offer nobody else sells, an internal onboarding standard. That is a genuine asset and it compounds every time you sign a client.

Buy one when the system is a system that thousands of businesses of your type all need, differing only in copy and branding. A full booking-and-follow-up system for a trade is roughly a week of the work described above, and a week is more than a snapshot costs. What is inside one, and what is not, is covered in what is a GoHighLevel snapshot.

Every system in our catalogue is built this way — a dedicated clean sub-account per trade, custom values throughout, prefixed naming, and a test load into an empty account before it ships.