What a GoHighLevel sub-account actually is, and what lives one level above it

A GoHighLevel sub-account is one client’s CRM. Contacts, conversations, pipelines, calendars, workflows, funnels, forms, phone numbers, reporting — all of it sealed off from every other client you run. The agency account sits one level above and owns the whole set.

That is the short version, and it is the version most guides stop at. The useful version is a description of exactly where the wall between the two levels sits, because almost every operational mistake an agency makes with GoHighLevel comes from assuming something is isolated when it is shared, or shared when it is isolated.

The two levels, described properly

The agency account is the container. It holds your plan, your billing relationship with HighLevel, your white-label settings, your team users, your snapshots, your agency-level API access and your list of sub-accounts. Nothing in it is client-facing unless you deliberately make it so.

A sub-account is a workspace. In the API it is still called a location, which is the older name and the one you will meet the moment you touch anything programmatic. One sub-account is intended to be one business. Not one campaign, not one funnel, not one location of a multi-site franchise unless that site genuinely runs its own diary and its own phone.

The mental model that survives contact with reality: the agency account is the shelf, a sub-account is the box. You can move a box between shelves. You cannot move half a box.

What is genuinely isolated

Everything a client would consider “their data” is per-sub-account:

• contacts, custom field values, notes, tasks and files
• conversations across SMS, email, calls, Facebook, Instagram and web chat
• opportunities, pipelines and pipeline stages
• calendars, availability and appointments
• workflows, triggers, campaigns and their enrolment history
• funnels, websites, forms and surveys
• the phone numbers attached to that account and the sending domain configured on it
• reporting, dashboards and attribution

A user with access to one sub-account cannot see another. That is the whole reason the structure exists, and it is why “just make a new pipeline in the existing account” is a bad answer when a new client arrives.

What is shared, and catches people out

• Your plan limit. Sub-accounts are counted at the agency level. On the entry plan you get a small fixed number; the higher agency plans lift the cap. Check HighLevel’s current pricing page before you promise a client an account — the tiers move.
• Your snapshots. A snapshot lives at agency level and is loaded into sub-accounts. One snapshot, many accounts.
• Your white-label domain and branding. Set once at agency level, seen by every client who logs in.
• Your team users. A user record is agency-level; what varies is which sub-accounts that user is permitted to open and what they can do inside.
• Your reseller relationships. Twilio or LeadConnector telephony, email sending, and any rebilling markup are configured up top and inherited down.
• Your reputation with carriers. This is the one nobody expects. A messaging compliance problem in one client’s account is not neatly contained; it is attached to a brand registration you own.

The sub-account ID, and why you will need it

Every sub-account has an ID — a short opaque string, visible in the URL when you are inside the account and in Settings → Business Profile. It is the value you will paste into API calls, webhook payloads, reporting joins and any middleware you build.

Two practical habits:

1. Record it at creation time, in the same row of the same sheet where you record the client name, the phone number and the sending domain. Retrieving twenty of these later, by hand, is an afternoon.
2. Never use the business name as the key in anything you build. Clients rename themselves. The ID does not change.

If you are already thinking in terms of a per-account record, you are thinking about a build sheet, which is the artefact that makes a portfolio of sub-accounts maintainable. Our sub-account launch checklist covers what belongs on it.

Standard sub-accounts and SaaS sub-accounts

There are two operating modes, and the difference is commercial rather than technical.

A standard sub-account is one you build, configure and maintain. The client logs in to use it; you do the work. This is agency-model delivery, and it is what most people mean when they say “sub-account”.

A SaaS sub-account is one that a customer provisions themselves by subscribing to a plan you have defined. The platform creates the account, loads your snapshot into it automatically, and starts rebilling usage at whatever markup you set. This is software-model delivery, and it changes what your snapshot has to be: it now has to work with nobody watching. We wrote about that difference in SaaS mode snapshots.

You can run both at once. Most agencies that get to scale do.

What a sub-account is not

• Not a copy of your agency account. Nothing in the agency account is present inside a sub-account by default. An empty sub-account is genuinely empty.
• Not a folder. There is no nesting. A sub-account cannot contain sub-accounts.
• Not free to run. Each one consumes phone numbers, email sending, AI usage and your time. See what a GoHighLevel sub-account actually costs for the arithmetic.
• Not portable by copy-paste. Moving a client to another agency is a specific platform action with specific exclusions. See transferring a sub-account to another agency.

The part that determines whether this scales

Here is the thing that separates an agency running four sub-accounts from one running forty: the four are built by memory and the forty cannot be.

A sub-account is a blank workspace. Everything useful in it — the intake logic, the follow-up sequences, the reminder cadence, the review request, the reactivation campaign — is something somebody has to build. Build it once by hand and you have a client. Build it forty times by hand and you have a staffing problem.

The structural answer is a snapshot: one account built properly, captured as a blueprint, loaded into every account after it. That is what a sub-account starter kit is — a snapshot built to be loaded repeatedly rather than admired once, with the client-specific strings pulled out into custom values so the same blueprint fits an HVAC contractor and a dental practice without either one reading like the other.

If you would rather not build the first one at all, our sub-account setup service does the create-configure-test pass and hands back the account with its build sheet.

Five decisions that are easier to make before the account exists

Every one of these is reversible, and every one of them is annoying to reverse once a client is live in the account.

One business or one location? A franchise with three sites and one shared phone line is one sub-account with three calendars. A franchise with three sites, three diaries and three managers is three sub-accounts. Get this wrong and you will spend a year explaining why the reporting does not split.

Who owns the phone number? If the client brings a number they already advertise, you are porting, and porting takes weeks. If you provision a fresh number, the client’s printed van livery still points somewhere else. Decide, then write the answer down before anyone builds a workflow that depends on it.

Which email domain sends? Sending from a subdomain you control is cleaner to authenticate and does not put the client’s primary domain reputation in your hands. Sending from the client’s own domain looks better in an inbox. Both are defensible; picking one after fifty thousand contacts have been mailed is not.

Who gets a login, and at what level? A client-level user who can edit workflows will eventually edit a workflow. That is not a hypothetical.

What happens if they leave? The answer should exist on day one, in writing, and it should match what the platform actually allows rather than what feels fair. Read what transfers and what does not before you write that clause.

Where to go next

• If you have never made one: creating a GoHighLevel sub-account, step by step.
• If you are budgeting: GoHighLevel sub-account cost.
• If you are choosing what to load into it: what is inside a good GoHighLevel snapshot.
• If you are doing this at volume: onboarding ten GoHighLevel clients in a month.