GoHighLevel Agency TrainingA Dynamic AI HUB training resource
Subaccount Basics

Subaccount structure overview

How subaccounts isolate data, users, and settings.

Beginner15 min

Purpose

This SOP explains how to think about subaccounts, locations, or client accounts inside an agency-style CRM system. A subaccount usually represents one business, brand, location, client, or operating unit. It keeps that account's contacts, opportunities, calendars, workflows, campaigns, users, and settings separated from other accounts. Good subaccount structure prevents data from mixing, users from accessing the wrong business, and automations from firing in the wrong place.

When to Use This SOP

  • Creating a new client account or location
  • Deciding whether a business needs one subaccount or more than one
  • Reviewing an inherited account structure
  • Preparing to apply a snapshot
  • Giving users access to a specific business or location
  • Separating brands, locations, or operating units

Before You Start

  • Do not create extra subaccounts just because the system allows it. Too many subaccounts can create unnecessary complexity. Too few can cause data and process confusion.
  • Before creating or changing subaccount structure, understand what business or brand the subaccount represents
  • Who owns the data
  • Which users need access
  • Whether contacts should be shared or separated
  • Whether calendars, workflows, pipelines, and reporting should be separate
  • Whether the business has multiple locations or just multiple services

Step-by-Step Procedure

  1. 1
    Define what the subaccount represents

    Write one clear sentence that explains the purpose of the subaccount.

    Examples:

    • This subaccount represents one local service business.
    • This subaccount represents one client location.
    • This subaccount represents one brand with its own contacts and workflows.
    • This subaccount represents a demo or testing environment.
    • This subaccount represents an internal training account.

    If you cannot explain what the subaccount represents, do not build inside it yet.

  2. 2
    Confirm data separation needs

    Decide whether data should be isolated.

    Subaccounts commonly separate:

    • Contacts
    • Conversations
    • Opportunities
    • Pipelines
    • Calendars
    • Workflows
    • Campaigns
    • Forms
    • Reports
    • Payments and documents
    • Users and permissions

    Use a separate subaccount when the data, users, reporting, or business process should remain separate.

    Do not use a separate subaccount just because the business has multiple offers. Multiple offers can often live inside one subaccount using pipelines, tags, fields, calendars, and workflows.

  3. 3
    Confirm user access needs

    List who needs access to the subaccount.

    For each user, document:

    • Name
    • Email
    • Role
    • What they need to do
    • Whether they should see contacts
    • Whether they should manage opportunities
    • Whether they should edit workflows
    • Whether they should manage calendars
    • Whether they should receive notifications

    Give users enough access to do their job, but not more than they need.

  4. 4
    Identify core operating assets

    Before building, document which assets this subaccount will need.

    At minimum, ask:

    • What pipeline or pipelines will this subaccount use?
    • What tags and fields will be needed?
    • What calendars will be needed?
    • What workflows will be needed?
    • What forms or lead capture assets will feed this account?
    • What email campaigns will be used?
    • What reporting views will matter?

    This gives the subaccount a build plan instead of becoming a blank container.

  5. 5
    Decide whether a snapshot will be used

    If a snapshot or template setup may be applied, review it first.

    Ask:

    • Was the source account clean?
    • Are the pipelines appropriate for this business?
    • Are tags and fields generic enough to reuse?
    • Are workflows disabled until reviewed?
    • Are calendars connected to the correct users?
    • Are custom values updated for this business?
    • Are email and SMS settings safe to use?

    Do not assume a snapshot is ready just because it exists.

  6. 6
    Avoid unnecessary subaccounts

    Do not create a separate subaccount only because:

    • A business has multiple services
    • A business has multiple lead sources
    • A team wants separate dashboards
    • A campaign feels different
    • A workflow is complex

    Those may be better handled with separate pipelines, tags, custom fields, calendar types, smart lists, reporting filters, or source tracking.

    Create a separate subaccount only when separation is actually needed.

  7. 7
    Document the subaccount

    Create a basic subaccount note.

    Include:

    • Subaccount name
    • Business or location represented
    • Owner or primary admin
    • Users with access
    • Main pipeline
    • Main calendars
    • Major workflows
    • Primary lead sources
    • Whether a snapshot was used
    • Date created or reviewed
    • Open setup items

Checks Before You Finish

  • ✓The subaccount purpose is clearly defined
  • ✓Data separation is justified
  • ✓Users and roles are documented
  • ✓Core operating assets are identified
  • ✓Snapshot use is reviewed, if applicable
  • ✓The subaccount is not being used to avoid proper structure
  • ✓A subaccount note exists
  • ✓The next build step is clear

Common Mistakes

Watch for these
  • Creating too many subaccounts
  • Mixing unrelated businesses inside one subaccount
  • Giving users access to the wrong account
  • Applying a snapshot without reviewing it first
  • Building workflows before defining the subaccount purpose
  • Using subaccounts to solve problems that should be solved with pipelines or tags
  • Forgetting to document which assets belong to the subaccount

Related SOPs

← Back to SOP Library