GoHighLevel Sub-Account Permissions & User Roles (2026)

By Dr Priya Jaganathan, GoHighLevel Certified Admin · HL Growth Partner, Australia · Updated 17 September 2026 · 8 min read

Some links below are affiliate links — if you sign up through them, HL Growth Partner may earn a commission at no extra cost to you. It never changes what we recommend. Full disclosure.

Most agencies get GoHighLevel sub-account permissions wrong in the same direction: everyone becomes an Admin because it is faster on the day, and nobody revisits it. Six months later a contractor who left in March still has a login, and a client can open the Workflows your whole delivery model depends on.

This is a practitioner's walk through the permission model as it actually behaves — the two separate layers of access, what the Admin and User roles really unlock, how the toggle list on a sub-account user works, what happens when you restrict someone to assigned data only, and how to build a role matrix that survives contractors, VAs and client logins. Written from Australian agency builds, so the privacy obligations are the ones you actually answer to.

HighLevel user roles sit on two layers that people constantly confuse

There is agency-level access and there is sub-account-level access, and they are configured in completely different screens. Mixing them up is the single most common cause of an agency accidentally handing a contractor the keys to every client.

Agency level: Settings > Team

From the agency view, Settings > Team is where you create people who exist above the sub-accounts — your business partner, your operations lead, your own logins. An Agency Admin can see and manage every sub-account, change global agency settings, and use Login As to drop into a client location.

Anyone you create at agency level should be someone you would trust with the client list itself, not just with the work inside one account. Agency-level access is portfolio-wide by nature; there is no clean way to hand someone the agency view and then hide half your clients from them.

Sub-account level: Settings > My Staff

Inside any individual sub-account, Settings > My Staff is where you add the people who work in that one location — the client's staff, the VA running their inbox, the specialist building their pipelines.

If a team member needs to work across four client accounts but has no business seeing the other thirty, you add them as a sub-account user in each of those four. They get a location switcher for exactly those accounts and nothing else. This is the pattern almost every agency should be using, and it is the foundation of setting up roles that genuinely protect client data rather than just looking tidy.

Admin vs User: what each GoHighLevel role actually unlocks

HighLevel keeps the role itself deliberately simple — Admin or User — and then layers granular toggles on top. Admin means full access to the modules and the settings of that sub-account. User means restricted access, shaped by whatever toggles you leave on.

The practical difference is settings, not features. A User can be given every module in the sidebar and still be unable to touch integrations, phone numbers, billing or the sub-account's own configuration — which is usually exactly what you want for a client.

Note the last two rows. Even a sub-account Admin is confined to that location — the client who runs their own account as Admin still cannot see your agency, your other clients, or your margins. HighLevel's own documentation on Admin versus User roles and permission scopes is worth keeping open while you configure your first few.

The permission toggle list on a sub-account user, category by category

HighLevel ships and renames toggles frequently, so quoting an exact count is a fool's errand — what matters is the categories, which have been stable for years. When you open a user in Settings > My Staff you are working through roughly these groups:

• Communication — Conversations, phone and call access, voicemail, SMS and email sending.
• Contacts and data — contact records, bulk actions, importing and exporting, custom fields and tags.
• Sales — Opportunities and pipelines, payments, invoices and products.
• Marketing assets — Funnels and websites, forms and surveys, the media library, social planner, blogs.
• Automation — Workflows, triggers, campaigns and bulk requests.
• Calendars — calendar management and appointment access.
• Reporting and AI — dashboards, attribution reporting, reviews, and the newer AI surfaces such as Conversation AI.
• Settings-adjacent — tags, custom values, triggers and other configuration that quietly shapes the whole build.

The two toggles that do the most damage when left on are bulk actions and export. A single careless bulk delete or a full contact export is not a training issue you fix afterwards — it is a data incident. Turn both off for anyone who does not need them weekly, and be equally deliberate about Workflows, because one person editing a live automation can break every client journey in the account.

Restricting a user to assigned data only — and where it bites

The Only Assigned Data toggle is the sharpest instrument in the whole model. Switch it on and the user sees only the contacts, conversations, appointments and opportunities assigned to them — everything else in the sub-account simply is not there for them.

It is ideal for a client with a sales team of five who should not browse each other's deals, or for a shared inbox where each rep owns their own conversations. It also filters dashboard widgets, so reporting reflects their book of business rather than the whole location.

The catch is that assignment only exists on records, not on assets. There is no way to assign a workflow, funnel or tag to a person, so this toggle does nothing to protect your build — it only narrows record visibility. If you need to protect the automation layer, that is a job for the module toggles, not this one.

The other thing to know: unassigned records become invisible. If your intake workflow does not set a contact owner, a restricted user will watch leads arrive in a pipeline they cannot open. Assign on creation, every time, or the restriction quietly breaks the client's day. It is the same discipline that stops a GoHighLevel setup from sliding into chaos in the first place.

Not on HighLevel yet? Start with a free 30-day trial here — long enough to build everything in this guide before you pay a cent.

What SaaS Mode clients can and cannot see in their own sub-account

Under SaaS Mode — available on the Agency Pro plan at US$497 per month in 2026 — you resell the platform under your own brand, set your own pricing, and bill through Stripe. The client signs up, a sub-account is provisioned, and they log in to what looks like your software.

What they see is their own location: their contacts, conversations, calendars, pipelines and whatever modules their role permits. What they do not see is your agency view, your other clients, your wholesale costs, or the margin structure behind your SaaS reselling model.

They can, however, see their own usage and charges in their dashboard — which is a feature, not a leak. Clients who can see what they are consuming raise fewer billing disputes. Price your rebilling so it survives being looked at.

The decision that actually matters in SaaS Mode is whether the client gets Admin or User in their own account. Give a non-technical client Admin and they will eventually open a Workflow "just to have a look". Give them User with Workflows switched off and your snapshot-based delivery build stays intact across every account you deploy it into.

A role matrix for an Australian agency running contractors and VAs

Design the matrix once, apply it to every new sub-account, and you never have to make the decision under pressure again. This is the structure we deploy for most Australian agencies with a small core team and offshore support.

The rule underneath the whole matrix is that nobody outside your core two or three gets agency-level access. Contractors and VAs are added per sub-account, which means offboarding one person is six clicks in six accounts rather than a frantic audit of everything you own.

If you are still deciding how much of the delivery work to hand to contractors at all, the trade-offs we see between using a VA versus building an internal implementation team land squarely on this question of access.

Australian privacy rules make GoHighLevel sub-account permissions a compliance question

If your agency or your client is covered by the Privacy Act, you are required to take reasonable steps to protect personal information — and access control is the most basic of those steps. A CRM holding client lead lists is exactly the kind of system regulators expect you to have locked down.

The numbers make the case better than I can. In the OAIC's Notifiable Data Breaches report for January to June 2025, human error accounted for 37% of all notified breaches — 193 notifications — with personal information sent to the wrong email recipient making up 44% of those human-error breaches, according to the OAIC's own 2025 breach statistics.

Every one of those is a permissions story before it is a security story. The person who sends the wrong list to the wrong contact usually had export rights they never needed. Tighten the toggles and you remove the capability, not just the temptation — and make sure your offboarding and data export process revokes access on the day the engagement ends, not the week after.

Common mistakes to avoid

• Making everyone an Admin because it is faster on setup day, then never reviewing it.
• Giving a contractor agency-level access so they can "switch between clients" — add them per sub-account instead.
• Leaving export and bulk actions enabled for staff who have never once needed them.
• Turning on Only Assigned Data without assigning an owner in your intake workflow, so new leads become invisible.
• Letting Workflows stay editable for non-technical clients, then rebuilding the automation they broke.
• Treating offboarding as a billing task — access should be revoked the same day, in every sub-account.

If you want your GoHighLevel agency permissions and role structure locked down properly, book a strategy call with the HL Growth Partner team.

Book Your Strategy Call →

Or if you just need the software first: grab the 30-day HighLevel trial and book us when you're ready to scale it.

Frequently asked questions

What is the difference between the Admin and User role in a GoHighLevel sub-account?

Admin gives full access to the modules and settings of that one sub-account, including the ability to add other users. User gives restricted access, shaped by the permission toggles you leave switched on, and generally keeps the person out of sub-account configuration. Neither role reaches beyond that single location.

Can I give someone access to several sub-accounts without giving them agency access?

Yes, and this is the correct pattern for contractors and VAs. Add the same person as a user inside each sub-account they work in, under Settings and then My Staff, and they get a location switcher covering only those accounts. They never see your agency view or your other clients.

What does the Only Assigned Data toggle actually restrict?

It limits the user to the contacts, conversations, appointments and opportunities assigned to them, and filters dashboard widgets to match. It does not restrict assets like workflows, funnels or tags, because those cannot be assigned to a person. Records with no assigned owner become invisible to that user entirely.

Can a sub-account user see my agency's other clients?

No. A sub-account user, including a sub-account Admin, is scoped to that single location and has no visibility of the agency view, other sub-accounts, or agency billing. Cross-client visibility only comes from agency-level access, which is why you should keep that list very short.

Do SaaS Mode clients see that the platform is HighLevel?

Not if you have configured your white-label branding and domain properly. SaaS Mode clients log in to your branded platform, see their own sub-account, and can view their own usage and charges. They do not see your agency view, your wholesale costs, or your other clients.

How should an Australian agency set permissions for an offshore VA?

Add them as a User at sub-account level in only the accounts they work in, never at agency level. Switch off export, bulk actions, payments and Workflows, and turn on Only Assigned Data if their work is limited to their own contacts. Given human error drives a large share of notified breaches in Australia, removing the capability is safer than relying on training alone.

Does removing a user delete their assigned contacts or conversations?

Removing a user removes their access; the contacts, conversations and opportunities belong to the sub-account and remain there. What you are left with is records whose assigned owner no longer exists, which can strip them out of pipelines and dashboards for other restricted users. Reassign that person's records before you remove them.

Related Articles on HL Growth Partner

Permissions and data governance

• GoHighLevel Roles That Protect Client Data
• Client Offboarding and Data Export in GoHighLevel (2026)
• GoHighLevel Health Check and CRM Optimisation

Agency build and scale

• SaaS Mode: Reselling HighLevel for Recurring Revenue
• Snapshots: Build, Sell and Deploy (2026)

Team structure and the Australian context

• The Hidden Cost of VAs vs an Implementation Partner
• Multi-Currency and GST for Australian Agencies