How to roll one snapshot across twenty GoHighLevel sub-accounts

Installing a snapshot into one sub-account is a task. Installing it across twenty, and still being able to change something in all twenty six months later, is an operation — and it is where most agencies discover that their snapshot was really a one-off.

This is the structure that makes a rollout survivable.

Before anything: know your ceiling

Sub-accounts are plan-gated in GoHighLevel. The entry agency plan allows a handful; the unlimited agency and SaaS tiers do not cap them. Some features a snapshot may reference are also plan-gated, which is how a snapshot imports “successfully” and then presents dead links.

Check two things in the agency dashboard before you plan anything: how many sub-accounts your plan permits, and whether your plan includes every feature the snapshot touches. Both are cheaper to find out now than at client eleven.

Step 1 — one canonical source per vertical

The rule that prevents the most pain: every vertical has exactly one source sub-account, and it is not a client’s.

That account is where the snapshot is built, where fixes are made, and where every new version is taken from. It has no real contacts, no live phone number, no connected payments. It exists to be the master copy.

The failure mode without it is drift. You fix a broken workflow in client 7’s account because that is where you noticed it, and now client 7 has a version nobody else has, the master does not have the fix, and the next install ships the bug again. Six months of that and you have twenty accounts that are all slightly different and none of which you can reason about.

If you did not build the snapshot, this still applies. Import the vendor’s snapshot into a clean sub-account you own, make your customisations there, and take your own snapshot from it. That account is now your canonical source, and the vendor’s link is upstream of it rather than the thing you deploy.

Step 2 — separate what varies from what does not

Go through the snapshot and sort everything into three buckets. This is the work that decides whether install eleven takes twenty minutes or three hours.

Identical everywhere. Workflow logic, pipeline structure, branch conditions, reminder timing, the funnel layout. This comes from the snapshot and is never edited per account.

Varies per client, and is a custom value. Business name, phone, address, booking link, service list, offer, hours, sending identity. Every one of these should be a custom value referenced everywhere, so an install is filling in a form rather than searching forty assets.

Varies per client, and cannot be a custom value. This is the reconnection list, and it is the irreducible per-account work:

• The phone number, provisioned and A2P registered
• The sending domain and its authentication
• Connected payment accounts
• The Google Business Profile for review posting
• User assignments on calendars and pipelines
• Any third-party integration

Nothing in the snapshot can carry those, because snapshots move configuration and not connections. Write the list down once per vertical and it becomes your install checklist forever.

Step 3 — roll out in waves of three

Do not install into twenty accounts on one afternoon. Do three.

The first wave is where you find out what the snapshot quietly assumed: that every client has a physical address, that every client wants Saturday appointments, that the service list has exactly five entries. Those assumptions are invisible in the source account because they were true there.

Fix what wave one surfaces in the canonical source, refresh, then do wave two. By wave three the install is mechanical and you can hand it to somebody else, which is the actual goal — a rollout you cannot delegate is not a rollout, it is a job.

For each account in a wave, the order matters and it is the same order as a single install, covered in full in how to install a GoHighLevel snapshot:

1. Fresh sub-account, or a deliberate decision to install on top of a live one.
2. Import.
3. Fill the custom values.
4. Work the reconnection list.
5. Run the customer journey yourself — book, miss the appointment, wait for the recovery call.
6. Switch campaigns on in order, not all at once.

Step 6 is the one that gets skipped under time pressure. Turning every campaign on simultaneously in a fresh account means the reactivation sequence starts working a list of contacts that were imported ten minutes ago and have no idea who this business is.

Step 4 — sequence the launches around A2P

Here is the constraint that reorders everything: A2P 10DLC registration is not in your control and it blocks SMS entirely. Unregistered traffic to US numbers is rejected at the carrier edge, not throttled — the messages simply do not arrive.

So registration cannot be step five of a rollout. It has to start the moment a client signs, in parallel with everything else, because approval time is variable and rejections require a resubmission cycle. On a twenty-account rollout, staggering registration is the difference between a two-week launch and a six-week one. What gets campaigns rejected, and how to fix them, is in the A2P guide.

Practical sequencing: register first, build while you wait, and design the launch so email and the AI receptionist can carry the account for its first week if SMS is still pending.

Step 5 — the update path

Once twenty accounts are running the same snapshot, you need a way to change all twenty. HighLevel supports this: refresh the snapshot in the source account so it picks up your latest changes, then push the update to selected sub-accounts that previously loaded it.

Two limits define what is possible. Updates only travel inside your own agency — accounts in someone else’s agency must re-import from a new link. And pushing adds and updates rather than reconciling, so a workflow the client edited locally and a workflow you changed centrally are a conflict you resolve by hand.

Which gives one operational rule worth enforcing: clients do not edit snapshot assets. If a client needs something different, it becomes either a custom value or a separate asset outside the snapshot’s prefix. The whole mechanic, including what refresh does and does not include, is in how to update a GoHighLevel snapshot.

What good looks like at twenty accounts

• One canonical source sub-account per vertical, owned by you, holding no live data.
• A written custom values list, filled in per account in one sitting.
• A written reconnection list, worked per account in one sitting.
• Prefixed asset names, so snapshot assets are distinguishable from client additions at a glance.
• A2P registration started at signature, never later.
• Updates pushed from the source, never edited in a client account.
• Waves of three, with the source fixed between waves.

That is roughly a day per vertical to set up and about ninety minutes per account after that.

If the twenty accounts are already sold and the day is not available, snapshot installation is that work done per account by the people who built the snapshot, and agency account setup is the agency-side structure it hangs off. Every snapshot in the library is licensed for unlimited sub-accounts precisely so a rollout costs you time and not licence fees.