GoHighLevel snapshot not loading: a diagnosis order that finds the cause in ten minutes

“The snapshot did not load” is almost never one problem. It is six different problems that produce similar-looking symptoms, and the fastest route through them is a fixed diagnosis order rather than poking at whichever asset you noticed first.

Work down this list. Stop at the first thing that is true.

1. You cannot see the Load Snapshot option at all

This is a permissions problem, not a snapshot problem.

Snapshot access is controlled from the agency, under user roles and permissions. A team member without it does not get an error — the action simply is not in the menu, which reads as the platform being broken rather than the account being restricted.

Check that the user has snapshot permission, and that they are acting at the right level. Some snapshot actions are agency-level only, and being inside the sub-account when you need to be above it produces the same “the option is missing” symptom.

2. The snapshot link expired, or was never shared with you

A shared snapshot arrives as a link. Links can be revoked, regenerated, or restricted to a specific agency. If you are importing someone else’s snapshot and the import screen rejects it, the answer is usually on their side.

Two follow-ups worth making before you assume the file is broken: ask whether the link is agency-restricted, and ask whether the snapshot has been updated since the link was issued.

3. Some assets loaded and some did not

This is the most common real failure, and it looks alarming because the account is now half-built.

Modern loads do not abort on the first failure — they continue and mark individual assets as failed. That is good news: you can retry just the failed assets rather than reloading everything, which matters because a full reload into an account that already has half the snapshot is how you get two of everything.

Order of operations:

1. Find the load report and list exactly which assets failed.
2. Retry only those. Transient timeouts are common and often succeed second time.
3. For anything that fails twice, open it in the source account and look for a dependency — a workflow referencing a calendar that did not come across, an email template referencing a missing custom value.

Dependencies are the usual cause. An asset that references something not present in the destination fails; fix the dependency, then retry.

4. Everything loaded, and now there are two of everything

Not a failure. Expected behaviour, in the wrong circumstances.

Loading a snapshot into a sub-account merges. It does not replace and it does not remove. If the destination already had a pipeline called Sales, you now have two pipelines called Sales, both listening, both reporting. Same for workflows, calendars, forms and tags.

Two workflows watching the same trigger both fire. That is the mechanism behind the client who received two confirmation texts for one booking.

The fix depends on how far you have gone:

• Nothing live yet — delete the duplicates, keeping the snapshot’s copies, and re-check every reference that pointed at the originals.
• Already live — do not delete anything with history attached. Unpublish one of each pair, confirm the account behaves, then clean up later.

The prevention is loading into an empty account. This is rule one of the snapshot loading method, and it is the rule most often broken by people who were “just setting up a calendar quickly” first.

5. It loaded, but nothing works

Structure arrived; nothing behind it did. This is not a bug, it is what a snapshot is.

A snapshot carries the shape of an account. It does not carry:

• credentials — payment processors, ad accounts, social channels, calendar authorisations, third-party API keys
• phone numbers and messaging compliance registration
• domains and DNS records
• contacts and conversation history
• the contents of custom values — the definitions travel, the strings usually do not

So a freshly loaded account has workflows that cannot send, calendars that sync to nothing and messages with holes where the business name should be. Every one of those looks like a broken snapshot and is actually an unfinished configuration pass. Work through the twelve settings in creating a sub-account properly.

6. It works, but it points at the wrong account

The subtlest failure, and the one that survives testing.

Trigger links, form redirects, calendar embeds and webhook URLs carry their structure in a snapshot, but the URLs inside them frequently still resolve to the account the snapshot was built in. Everything appears to work — the link opens, the form submits — and the data lands in somebody else’s CRM.

Walk every asset that contains a URL: trigger links, form and survey redirects, calendar embed codes, webhook URLs in workflows, and any link inside an email or SMS template. This is step four of the loading method and it is the step self-serve installs skip most often.

7. Dashboards and reports came across empty

Dashboards depend on the pipelines, stages and custom fields they report on. Loaded in the wrong order, or with a dependency that failed at step three, they arrive as an empty frame.

Confirm the underlying assets exist and are named as the dashboard expects, then reload just the dashboard rather than the whole snapshot.

8. Nothing above applies

Then check the boring things before assuming a platform fault: are you within your plan’s sub-account limit, is the destination account actually active, and has the snapshot been rebuilt since you last downloaded it? A snapshot is a point-in-time capture, and loading last quarter’s version of a kit into this quarter’s account produces failures that make no sense until you notice the version.

A ten-minute triage script

When something is wrong and you do not yet know which of the eight it is, this order gets you to the answer fastest:

1. Can you see the load action? No → permissions (case 1). Yes → continue.
2. Did the load report list failures? Yes → case 3. No → continue.
3. Are there duplicate assets? Yes → case 4. No → continue.
4. Does a test SMS send? No → case 5, credentials and compliance. Yes → continue.
5. Does a test form submission appear in this account? No → case 6, wrong-account URLs.
6. Are the dashboards populated? No → case 7.
7. Still wrong? Case 8, and check the snapshot version before opening a support ticket.

Each check takes about a minute. Doing them in this order matters because the later symptoms mask the earlier causes — an account with the wrong URLs in it also looks like an account where nothing works.

What to write down while you fix it

Every one of these failures is one you will meet again on the next install. Keep a per-kit note of:

• which assets failed and why
• which dependencies had to exist before which
• which URLs needed re-pointing
• which settings the snapshot could never have supplied

After two or three installs that note becomes a load sheet, and the fourth install stops being troubleshooting and starts being a procedure. That transition is the whole difference between an agency that dreads installs and one that batches them — which is the subject of onboarding ten clients in a month.

The habit that prevents most of this

Load into a blank sub-account, in a known order, with a written list of what the account still needs afterwards. That list is the load sheet, and it is the reason our sub-account kits ship with one — an ordered set of custom values, the dependency order for publishing workflows, and the explicit list of what the snapshot deliberately does not carry.

If an install has already gone sideways in a live account and you would rather someone else untangle it, snapshot loading and account migration is a service, and it starts with a conflict report rather than a load.