Setting up a new GHL sub-account: the build order that avoids rework

A new client signs. The temptation is to open a fresh sub-account and start where the client's attention is: the lead follow-up workflow, the booking reminder, the review request. That is the visible part, so it feels like progress.

It is also the part that depends on everything else. A workflow points at a pipeline stage, a custom field, a user, a calendar, a sending number and a from-address. Build it first and every one of those references is either missing or provisional, and you will be back inside that workflow in a week, re-pointing actions at the things you built afterwards.

Almost all the rework I have seen in new accounts comes from building in the wrong order, not from building the wrong thing. So here is the order I use. Each layer only points at layers that already exist and have been checked, and nothing has to be torn up later.

The rule underneath the order

Build from the bottom of the dependency chain upward. A GoHighLevel account has a rough stack: the account itself, the access you use to work in it, the business identity and custom values, the messaging channels, the outside connections, the data structure, and finally the automation that ties them together. Every layer above references layers below it. Nothing below needs to know about the layers above.

That is why workflows go last. They are the most referential thing in the account, and they are the most expensive thing to fix when a reference moves. We wrote about what happens when one of those references stops resolving in how invalid IDs kill GHL automations without showing an error. A good build order is mostly a way of never creating that problem in the first place.

Step 1: create the account with the snapshot already in it

If you run a standard client build from a snapshot, load it at creation rather than into an account you have already started working in.

The reason is the conflict check. HighLevel's guide to loading a snapshot into an existing sub-account walks through it: you pick the assets to import, review conflicts, and for each conflicting asset choose Override, which replaces the existing item with the snapshot version, or Skip, which keeps what is there. The same guide warns that once you override an asset, the snapshot load cannot undo it. An empty account has nothing to conflict with, so the whole decision disappears.

Two things to have ready before you click create: the client's real business name and address, and the correct timezone. In our experience the timezone is the field most often left at a default, and calendars, appointment reminders and anything that respects a send window are only as right as that setting.

Then wait. A snapshot load is not instant. HighLevel's guide notes that after you confirm, an email is sent once the information has been transferred. Our own provisioning notes say the same thing in operator terms: snapshots load asynchronously on GoHighLevel's side, so give it a minute or two before expecting every asset to be there. Building into an account while the snapshot is still landing is a good way to create the conflicts you just avoided.

If you create accounts through the API rather than the agency view, HighLevel's Create Sub-Account endpoint takes an optional snapshot ID to be loaded into the new location, along with fields like name, address and timezone. The documentation notes the endpoint is only available on HighLevel's Agency Pro plan.

Step 2: set up access before you need it

Decide how you are going to work in the account before you start working in it, because access is the one layer that is painful to retrofit.

For people, that means adding the client's team and your own staff with the right roles now, so that anything you build later can be assigned to a real user rather than to whoever happened to be logged in.

For tools, that means a Private Integration. HighLevel's private integrations article says they exist at both the agency and sub-account level, that the token is shown once and you will not be able to copy it again later, and that HighLevel recommends rotating tokens every 90 days. It also documents that you can now edit an integration's name, description and scopes after creation without generating a new token.

The part that catches agencies is the boundary between the two levels. An agency-level token is what creates the sub-account. In our operating experience it is not what reads or writes the contacts, workflows and pipelines inside it. Each new location needs its own token, created inside the sub-account, before any tool can build there. It takes a couple of minutes, and it is much easier to do on day one than to discover on day four when an integration quietly cannot see the account.

Step 3: identity and custom values

Now fill in who the business is. Business profile, address, phone, website, and the custom values your snapshot uses for things like the business name, booking link and sign-off.

HighLevel's snapshot overview lists custom values among the CRM and data structure assets a snapshot carries, alongside custom fields, pipelines, tags and smart lists. That is useful and it is a trap. The custom value arrives, but whatever it held in the source account arrives with it or arrives empty, and a message that references it will send either way. A custom value pointing at another client's booking link, or at nothing, is a real message to a real contact.

So go through every custom value the snapshot brought in and set it for this client before anything that uses one can fire. This layer is boring, and it is the one that prevents the most embarrassing support tickets.

Step 4: phone number and A2P, early

Start messaging compliance in the first hour, not the last, because it is the step with the longest wait and the least control.

HighLevel's explanation of A2P 10DLC brand and campaign registration separates the two pieces: the Brand identifies who is sending, and the Campaign covers what is sent and why, including sample messages and the consent process. It is explicit that carriers and their registration partners make the final decision, not HighLevel. After approval, each number should show the A2P Verified label under Settings, Phone System, Phone Numbers; a number without it needs to be linked to the approved campaign before you send, and carrier systems may take several business days to receive the update.

Add the number, submit the registration, and let that clock run while you do everything else. If you want the list of what gets these submissions rejected, we covered it in the A2P 10DLC submission mistakes that get GHL agencies denied. The practical rule for build order: no SMS workflow gets published until the number it sends from shows verified.

Step 5: the email sending domain

Email has its own lead time, for different reasons. A dedicated sending domain means DNS records at the client's domain host, which means waiting on whoever controls that DNS, and then waiting on propagation. A brand new sending domain also has no reputation yet, so it should not be the first thing to carry a large send.

Set it up now, while A2P is pending, so that by the time workflows exist the from-address they use is the real one. Changing sender details after the fact means touching every workflow and template that set them.

Step 6: reconnect what the snapshot could not bring

HighLevel's snapshot overview is direct that integrations and third-party account connections do not transfer, and lists Stripe connections among the exclusions. It also notes that some assets may need connected integrations, approvals or post-load configuration before they work in the destination account.

In practice that means calendars connected to the right people's calendars, payments connected to the client's own processor, and any outside tool that posts into the account wired up and tested. Do it before workflows, because a booking workflow built against a calendar that is not connected yet looks fine and does nothing.

Step 7: verify the structure, then freeze it

Before any automation, read the data structure the snapshot delivered: pipelines and stages, custom fields, tags, calendars, forms. Rename what needs renaming. Add the fields this client needs and the template did not have.

What you should not do is delete and recreate. A recreated pipeline stage or custom field is a new object with a new ID, and every snapshot workflow that referenced the old one now points at nothing. Edit in place. This is the same failure mode we described in why GoHighLevel snapshots break, and the new-account version of it is entirely self-inflicted.

Once the structure is right, treat it as frozen. Anything that changes after this point is a change to something workflows depend on, and should be handled like one.

Step 8: workflows last, one at a time

Now build or adapt the automation. Every reference a workflow needs exists, has been checked, and is not going to move.

Work in draft. Run each workflow with a test contact that belongs to you, read the result, and publish one at a time, starting with the ones that do not send anything to the client's customers. The sending workflows go live last, after the number shows A2P Verified and the sender details point at the real domain.

Then write down the baseline: the published workflows, the pipelines and stages, the custom values you set, the users and the token you issued. When something changes in three months, you will want to know what it looked like the day you handed it over.

The order, on one screen

• Create with the snapshot. Correct name, address and timezone. Wait for the load to finish.
• Access. Users with real roles. A location-level token for any tool that will build there.
• Identity and custom values. Every custom value set for this client before anything can send.
• Phone and A2P. Submitted early. No SMS workflow published until the number is verified.
• Email sending domain. DNS started early, real sender details before any template is finalized.
• Integrations. Calendars, payments and outside tools reconnected and tested.
• Structure. Pipelines, stages, fields and tags checked, edited in place, then frozen.
• Workflows. Draft, test contact, publish one at a time, senders last. Baseline recorded.

Where the time actually goes

Done by hand, most of this is clicking: the agency view to create the account, the sub-account settings to issue a token, the conflict screen, the custom values list, then node by node through every workflow to confirm its references resolve. It is not hard. It is just long, and it is the kind of long that tempts people to skip the verification steps, which are the only ones that prevent rework.

GHL Command is how I run this on my own client builds. With an agency-level Private Integration registered, Claude can create a client sub-account from one sentence with the snapshot loaded at creation and hand back the new location ID. Once that location has its own token, it can read and build inside it, including checking every workflow's actions against the pipelines, stages, fields and users that actually exist, which is the verification step people skip. It runs from Claude on your own machine, so client credentials stay on your computer, and it works across every sub-account rather than one at a time, which is the case we made for running an agency from one place.

Flat $97/mo, every sub-account you manage included, never billed per account. Onboard ten new clients and the price does not move.

Frequently asked questions

Should I load the snapshot at creation or afterwards?
At creation when you can. Loading into an account that already has assets puts you through the conflict check, where each conflict is overridden or skipped, and HighLevel notes an override cannot be undone by the load. Either way, wait for HighLevel's completion email before building on top.

Can an agency-level token build inside a client sub-account?
In our operating experience, no. The agency-level token creates the account; reading and writing that location's contacts, workflows and pipelines needs a token issued inside the sub-account. HighLevel shows each token value once and recommends rotating every 90 days.

When should A2P start on a new account?
In the first hour. Carriers and their registration partners make the decision, each number has to be linked to the approved campaign and show A2P Verified, and HighLevel notes carrier systems may take several business days to receive the update.

Why build workflows last?
A workflow is mostly references to pipelines, stages, fields, users, calendars and senders. Build and verify those first and the workflow is written once against a settled account instead of being re-pointed every time something underneath it changes.