How to Install a GHL Snapshot in a Sub-Account

Importing a snapshot takes minutes. Making the account actually work takes longer, and the gap between those two facts is where most bad hand-overs happen. This is the sequence we run on every install, in order, including the things that never carry across and the QA pass we do before a client is allowed to log in.

Before you import: three pre-flight checks

1. Install into a clean sub-account

Snapshots add content, they do not replace it. Loading one into an account that already has pipelines, calendars and custom fields gives you two of everything and a confused client. Create a fresh sub-account unless there is a hard reason not to.

2. Check for name collisions

If you must install into a populated account, list the existing pipelines, calendars, custom fields and phone numbers first. Anything with a name the snapshot also uses will need renaming afterwards, and you want to know that before, not after.

3. Confirm plan feature parity

Snapshots can reference features the destination plan does not include. If the build uses features your client’s plan lacks, those steps import but never run. Check before you promise a date.

Step 1 — Load the snapshot into your agency

A seller sends you a share link. Redeeming it loads the snapshot into your own agency, where it becomes available to push into any sub-account you own.

1. Open the share link while logged in as an agency-level user.
2. Confirm the import. The snapshot now appears in your agency’s snapshot list.
3. Rename it with a version and a date — Home Services v4 · 2026-07 beats Home Services (2) when you have nine of them.

Redeeming the link does not touch any client account yet. It only stocks your shelf.

Step 2 — Push it into the sub-account

From the agency view, choose the snapshot and the destination sub-account, then load it. Depending on size this takes two to ten minutes, and it runs in the background — do not close the tab and assume it failed because nothing appeared instantly.

When it finishes, the sub-account has the structure. It does not yet have a single working connection.

Step 3 — What did not carry across

This is the list to work through, and it is the same every time.

Travels with the snapshot	Does not travel
Funnels and websites	Contacts and conversations
Workflows and triggers	Integration connections (payments, email, social)
Pipelines and stages	Phone numbers and A2P registration
Calendars (structure)	Calendar owners and connected personal calendars
Custom fields and custom values	Values themselves, if the seller cleared them
Email and SMS templates	Verified sending domain and DNS records
Forms and surveys	Media library files referenced by URL
Dashboards and reporting widgets	User accounts and permissions

Everything in the right-hand column is manual work. Budget for it.

Step 4 — Populate the custom values first

Do this before you touch anything else. In a well-built snapshot, thirty to forty custom values hold every client-specific detail: business name, address, phone, booking link, offer, price points, review link, opening hours. Filling them in makes most of the account correct in one pass.

If the build hardcodes those details into individual workflow steps instead, you have bought a weak snapshot — and it is worth knowing that on day one rather than in month three. Our snapshot catalog lists the custom-value count on every spec sheet for exactly this reason.

Step 5 — Rebuild the calendars

Calendars import as structure but arrive ownerless. For each one:

1. Assign the correct user as owner.
2. Reconnect that user’s personal calendar for conflict checking.
3. Set availability, buffers, slot duration and minimum notice.
4. Rebuild round-robin distribution if the build uses it.
5. Copy the new calendar’s booking link into the matching custom value.

Step five is the one people forget, and it is why “the booking button goes to the old client’s calendar” is the single most common post-install bug.

Step 6 — Reconnect the integrations

Work through them in this order, because later ones depend on earlier ones:

1. Sending domain and DNS. SPF, DKIM and DMARC on the domain the client will actually send from. Verify before sending anything.
2. Phone. Provision the number, then submit A2P brand and campaign registration. Registration takes days, so start it early rather than on launch day.
3. Payments. Connect the processor and re-map any product or price the funnels reference.
4. Inbox and social. Connect the mailbox, then any social or messaging channels the workflows send through.
5. Third-party tools. Anything the build talks to over webhook needs its URL repointed at the new account.

Step 7 — Repoint the loose ends

• Trigger links still point at the source account’s URLs.
• Funnel domains need the client’s domain attached and SSL confirmed.
• Redirects inside funnels may reference the old paths.
• Media loaded by absolute URL may still be served from the source account.
• Workflow publish state. Confirm every workflow that should be live is published, not sitting in draft.

Step 8 — The QA pass

This is the part that separates an install from a hand-over. Create a real test contact with a real email address and a real phone number you control, then walk the entire journey.

The checklist we sign off against:

1. Every form submits and lands the contact in the right pipeline stage.
2. Every workflow that should fire on that submission does fire — check the execution log, not just your inbox.
3. Every email arrives, renders on mobile, and has no unresolved merge fields.
4. Every SMS arrives and carries opt-out language.
5. Every booking link opens the right calendar, with the right owner and the right availability.
6. Every payment link charges the right amount to the right processor in test mode.
7. Every pipeline automation moves the contact to the stage it claims to.
8. Every dashboard widget resolves and shows data rather than an error.
9. No workflow references a deleted asset — the error log will tell you.
10. Delete the test contact and confirm nothing breaks when it is gone.

Write down what passed. We hand clients a one-page QA report because a list of tested items is worth more than a reassurance, and it is included as standard in our snapshot installation service.

Step 9 — Hand over properly

Give the client, or your own account team, three things: the account, a recorded walkthrough of the build, and a written spec sheet listing every setting, every credential holder and every decision. If the person who installed it leaves, the spec sheet is the only thing standing between you and a rebuild.

Common failure modes

• Workflows in draft. Imported workflows are frequently unpublished. Check every one.
• Booking links pointing at the source account. Fixed by step five, missed constantly.
• Unauthenticated sending domain. The automation is fine; the email is going to spam.
• A2P started on launch day. Registration is not instant. Start it in week one.
• Duplicate custom fields. Caused by installing into a populated account. Merge or delete rather than leaving both.

What to do next

If you are installing your first snapshot, block a full day and follow the order above — the sequence matters more than the speed. If you would rather have it done and handed over with a QA report attached, our snapshot installation service covers the whole list for a flat fee, or you can book a call and we will scope it. If you are still deciding which build to install, start with what a GHL snapshot actually is.