How to create a GoHighLevel sub-account properly, before anything is loaded into it

Creating a GoHighLevel sub-account is four fields and a button. Agency view, Sub-Accounts, Create, name and address and email, done. Nobody needs a guide for that part.

What people actually need is the order of everything around it — because a sub-account created in the wrong order has to be half-rebuilt, and the rebuild always happens after a snapshot is already in there making copies of the mistake.

This is the sequence we use. It assumes you are building a real client account, not a sandbox.

Before you click Create

1. Collect the client data first

You cannot fill in a business profile from memory, and a half-filled profile propagates into every message the account ever sends. The minimum set:

• legal business name, exactly as it appears on tax registration
• trading name, if different — this is what appears in SMS
• registered address and the address customers actually visit
• business phone, business email, website URL
• time zone
• the two or three services the business actually sells, in the words the business uses

The legal name matters more than it looks. Messaging compliance registration is checked against government filings, and a mismatch between what you typed here and what is on the client’s IRS paperwork is the single most common cause of a rejected brand. See GoHighLevel A2P 10DLC registration.

2. Decide the account’s identity, not just its name

Name the account so it sorts usefully in a list of forty. Northgate HVAC — Denver beats Client Account 12. If you run several verticals, prefix by vertical so the list groups itself. Whatever convention you choose, it must be the same one you use for workflows and tags inside the account — see naming conventions that survive a second builder.

3. Decide whether this account will receive a snapshot

If yes — and it usually should — create the account empty and leave it empty. Do not “just set up a calendar quickly” while you wait. Loading a snapshot into an account that already has assets is how you get two calendars, two pipelines and two workflows listening to the same trigger. The snapshot loading method explains why.

Creating the account

From the agency view, open Sub-Accounts and create a new one. You will be offered the option to create it from a snapshot. Take it if you have one — it is cleaner than creating blank and loading after, because the account has no prior assets to conflict with.

The fields you fill here become the account’s business profile, and the business profile is the source for the default sending identity, the SMS sender name, the address in email footers and the data used for compliance registration. Fill them properly now; they are tedious to correct in six places later.

The twelve settings that matter next

In rough dependency order:

1. Time zone. Everything scheduled — reminders, sending windows, reporting days — inherits it. Wrong time zone means 3am reminders, and you will find out from the client.
2. Business profile completeness. Legal name, address, EIN if you have it, website.
3. Phone number. Provision or port. Nothing that sends SMS can be tested until this exists.
4. Messaging compliance registration. Start it immediately; approval is measured in days, not minutes, and it gates every SMS in the account.
5. Sending domain and email authentication. A dedicated sending subdomain with SPF, DKIM and DMARC records published. Email that is not authenticated does not reliably arrive.
6. Email “from” identity. Name and reply-to address, matched to the domain above.
7. Calendar ownership. Whose diary is this, which external calendar is it synced to, and what is the real availability? Not the availability the client wishes they had.
8. Users and permissions. Who from the client’s side gets in, and at what level. Default to the least access that lets them do their job.
9. Payments, if the account will take money. Connect the processor before any funnel references it.
10. Integrations. Ad accounts, Google Business Profile, social channels. These carry credentials and are never included in a snapshot — they are always a manual connection.
11. Custom values. Every client-specific string the account will ever print in a message. Fill them before the first test send or you will test a message with a hole in it. See custom values vs custom fields.
12. Reporting and dashboards. Last, because they depend on everything above existing.

Steps 4, 5 and 10 are the three that cannot be rushed and are the three most often skipped. They are also the three that a snapshot cannot do for you.

Then, and only then, load the kit

With the account created and the twelve settings done, loading the snapshot is genuinely a click, followed by a test pass. That is the whole point of doing it in this order: the risky work is finished before any automation is capable of sending.

If the account came pre-loaded from a snapshot at creation time, run the same list anyway — the snapshot carries structure, not credentials, and every item above is either a credential, a setting or a client-specific string.

A worked scenario, with the assumptions printed

Suppose you are onboarding one new client a fortnight, and you have no kit. Assume a first-build account takes you a day of focused work: intake, structure, workflows, copy, calendars, testing. That is roughly 8 hours per account, and it scales linearly — ten clients is ten days.

Now assume you have a kit that already contains the nine automation components configured for that vertical, and a load sheet listing the custom values in the order they appear. The twelve settings above still take about 90 minutes because they are credential work nobody can automate away. The build itself becomes a load and a test pass — call it another 90 minutes.

That is 3 hours instead of 8, on those assumptions. Substitute your own numbers; the shape of the result does not change, because the fixed cost is the credential work and the variable cost is the build. A kit removes the variable cost and leaves the fixed cost exactly where it was. Anyone who tells you a snapshot removes both is selling you something.

Four mistakes that cost a rebuild

Building in the client’s live account “temporarily”. There is no temporary. The moment a real contact enters, you cannot delete freely, and every subsequent snapshot load merges into whatever you improvised.

Testing with the client’s own phone number. Use a number you control. You will send the same test message eleven times while you get the exit conditions right, and the eleventh one is the one the client screenshots.

Turning workflows on before the compliance registration is approved. Messages queue, fail, or silently drop depending on the path, and the workflow history then contains a fortnight of noise you have to read past every time you debug something else.

Skipping the write-up. An account nobody documented is an account only its builder can maintain. Write the build sheet as you go: account ID, phone number, sending domain, which custom values are filled, which workflows are published, what is deliberately switched off. It takes fifteen minutes during the build and saves an afternoon in three months.

What to do when the account is live

Two things, on a schedule:

• A monthly walk of the exit conditions. Sequences that do not stop are the most common silent failure in a busy account, and they only reveal themselves under volume. Our note on testing workflows before go-live is written as a pre-launch pass, but the same walk works as a monthly check.
• A quarterly settings audit. Domains expire, integrations disconnect, staff leave and their calendar sync goes with them. Nothing in the platform tells you; the client tells you, usually loudly.

Doing this more than a few times

If you are creating accounts one at a time through the interface and you have a portfolio to roll out, stop and read creating sub-accounts in bulk — the API and SaaS mode both create accounts far faster than a human can type, and the constraint becomes the configuration rather than the creation.

And if you want the account to arrive already built for the vertical, the 22 sub-account kits are exactly this process pre-packaged: one per niche, nine components each, with the load sheet that tells you which of the twelve settings above the kit still needs from you.