GoHighLevel Agency Architecture: Sub-Accounts, Snapshots, Plans and Usage

Short answer: GoHighLevel looks like one big dashboard, but it is separate layers. The agency view controls the business. Each client gets an isolated sub-account. A clean source sub-account produces a snapshot. The plan controls commercial access. A written usage path shows who is charged first and how cost is recovered. Mixing these layers causes expensive mistakes.

Written by Sawan Kumar, Chartered Accountant and AI educator. Adapted from the AI SaaS Agency course. Last verified: 28 September 2026.

Interface labels, plan names and billing paths change. Everything below was checked against HighLevel's help documentation on 28 September 2026. Recheck in your own account before relying on it.

Why the layers matter

Mix the layers and you can give a client too much access, copy private data into a reusable template, deploy the wrong assets or misunderstand who pays for usage. The goal is not a feature tour. It is knowing where each part belongs, who controls it and who pays when it creates a cost.

Layer 1: the agency view

This is where agency admins oversee sub-accounts, higher-level access, SaaS products and billing settings. It is not the client's daily workspace.

An agency admin is not the same as a client admin. An agency admin can control agency-level areas across many sub-accounts. A sub-account admin controls only assigned locations.

Give the least access needed. A receptionist who needs the inbox and calendar does not need agency billing or other clients' accounts. See HighLevel's guide to sub-account user roles and permissions.

Layer 2: client sub-accounts

Each live client needs an isolated sub-account, also called a location. That is where its contacts, conversations, calendars, users, workflows and reporting live. One HVAC client must never share live data with another.

Naming trap: HighLevel may also use the term Agency Sub-Account for an internal location the agency owns. In some SaaS billing setups it has a commercial role. It is still a sub-account. It is not the agency view, and it is not the client's live location.

Label every workspace by purpose: agency control, agency internal or selling sub-account (if used), clean source and test sub-account, or live client sub-account.

Layer 3: clean source sub-account and snapshot

Build the generic system in a clean source or test sub-account. It can hold generic workflows, forms, calendars, pipelines, templates, dashboards and fictional test records.

Then create a snapshot from it. A snapshot is a reusable package of selected configuration assets. See the HighLevel snapshots overview.

A snapshot must never carry another client's contacts, credentials, private data or business-specific claims.

After loading it into a client sub-account, verify the client-specific items: phone, email, payment, domain, users, calendar availability, business hours, integrations and consent language. Then run one test lead end to end. It passes only when the lead reaches the right account, gets the approved response, follows the right route and produces the expected booking or notification.

Layer 4: plans and access

The snapshot answers what setup is deployed. The plan answers what the client is buying and what access that creates.

In a supported SaaS checkout, a plan can link payment, sub-account creation, a snapshot, customer access and a subscription. That automation is still not proof of delivery.

Also, not every account uses the same SaaS billing setup. HighLevel's documentation distinguishes SaaS V1 and SaaS V2, and the system of record can differ. Before onboarding, identify your version, where the subscription is controlled, which payment connection is used and where troubleshooting starts. The SaaS Configurator guide is the starting point. Do not copy an old tutorial because the screen looks familiar.

Layer 5: usage and billing

Client activity creates metered usage: phone, messaging, email, AI and more. The activity happens in the client sub-account, but the first charge and the final recovery may sit in different places.

For supported LC services, HighLevel's rebilling, reselling and wallets guide says the agency wallet is charged first. With rebilling or reselling configured, the agency can recover cost from the client.

Before launch, answer five questions:

1. Which wallet is charged first?
2. Is cost absorbed, passed through at cost, or marked up?
3. What payment method reloads the balance?
4. What limit or alert controls usage?
5. What happens if the client's payment fails?

Never write only "the client pays usage." Write the real path. For example: "The client creates messaging usage in its sub-account. The agency wallet is charged first for supported LC services. Rebilling recovers eligible usage without markup. The agency checks failed recharges and low-balance alerts." That statement can be tested.

The architecture at a glance

Layer	Correct purpose	Never put here
Agency view	Agency-wide control and oversight	Client daily operations
Clean source sub-account	Generic reusable build and tests	Live client contacts or credentials
Client sub-account	One client's operations and data	Another client's data
Snapshot	Selected reusable configuration	Private data or client-specific claims
Plan and access	What is bought and what access it creates	Proof that delivery works
Usage path	Charge, recovery, limits, failure response	Assumptions you have not verified

Write your architecture record

On one page, record agency responsibilities, any internal or selling sub-account, source sub-account rules, the client boundary, snapshot contents and exclusions, your V1/V2 path, the usage path, user permissions, client connections to verify, and who owns which assets and data.

If you cannot verify your SaaS version, subscription record, wallet path or required reconnections, write "not verified" and add it to your launch checklist. Do not guess. Part 8 decides which work inside this system belongs to AI, fixed rules or people.

The full series

This article is part of a step-by-step series on building an AI SaaS agency on GoHighLevel. Read it in order:

1. Part 1: How to Build an AI SaaS Agency Step by Step
2. Part 2: The AI SaaS Payback Method: Pick, Package, Pitch, Profit
3. Part 3: Choosing Your AI SaaS Niche: Follow a Reference Build or Pick Your Own
4. Part 4: A 7-Day Validation and 30-Day Launch Plan for an AI SaaS Agency
5. Part 5: SaaS vs Managed Service vs Hybrid: What Your AI Agency Really Sells
6. Part 6: Why Recurring Revenue Can Still Be a Bad Business (MRR Is Not Profit)
7. Part 7: GoHighLevel Agency Architecture: Sub-Accounts, Snapshots, Plans and Usage (you are here)
8. Part 8: Where AI Adds Value, and Where Rules or Humans Are Safer
9. Part 9: Is GoHighLevel the Right Platform? A Fit Test Before You Commit