GoHighLevel User Permissions: How Roles Actually Work

GoHighLevel user permissions sit on two separate layers, and most confusion comes from mixing the two up. One layer controls what a person can do across the whole agency.

A second, independent layer controls what they can do inside one client's account. Confuse them and you'll either lock out a teammate who needed access, or hand a new hire more reach than you meant to give.

What Agency Admin and Agency User actually control

At the agency level, HighLevel only recognizes two roles. An Admin role "provides administrative capabilities within the user's applicable access scope," while a User role is limited to whatever permissions you configure for them, according to HighLevel's documentation on agency roles.

Agency Admins get two things by default that Agency Users don't: processing affiliate payouts, and using "Login As" to open a client's sub-account as if they were that client.

A separate setting, User Type, trips people up because it looks like the role itself. It decides scope rather than authority. An Agency User Type gets access across the agency; an Account User Type is boxed into whichever sub-accounts you've assigned.

You configure all of it from the agency view: Settings, Users, the person you're editing, then Roles & Permissions. Pick the User Type first, then the role, then the modules they can see.

Getting that sequence right is most of what a proper GoHighLevel setup is doing in the background.

Inside a sub-account, GoHighLevel user permissions split again

Once you're inside a client's account, the same split happens again, as Account Admin and Account User.

HighLevel's documentation on admin versus user permission scopes groups permissions into three buckets: agency-only, like SaaS mode and white-label settings; sub-account-only, like one pipeline or calendar; and permissions available at both levels, including workflows and reporting.

Agency-level access always wins where the two overlap. Permissions "don't cancel out, they stack, with the broader Agency permissions always taking precedence," the documentation states. Trying to rein in an Agency Admin by changing a setting inside one sub-account won't hold.

To adjust someone's permissions inside a sub-account, go to Settings, then My Staff, click the pencil icon next to their name, and expand User Roles. Our walkthrough on GoHighLevel sub-account setup covers the order to build that structure in.

A handful of permissions are sensitive enough that HighLevel pulls them out for separate review:

• Creating or deleting sub-accounts
• Changing sub-account settings
• Managing other users
• Using "Login As" to act as a client
• Exporting dashboard data
• Transferring a sub-account to a different agency

Sub-account transfer defaults to the agency owner alone. It's opt-in, not bundled with the Admin role, which matters for any agency running white-label support across several client accounts.

Why a plan can cap a user's access before you set a single permission

There's a ceiling above all this with nothing to do with roles. A sub-account's plan, set through the SaaS Configurator, fixes what's available before any permission is touched.

HighLevel's guide to SaaS user-level versus sub-account-level permissions is direct: "A user cannot access a feature that is unavailable at the sub-account level." Check that first, not the staff settings.

Dashboards carry their own version of this layering, with four tiers.

Dashboard tier	What it allows
Full	Create, edit, share and delete dashboards
Edit	Modify dashboards and widgets, no deletion
View	Read-only access to existing dashboards
No Access	Dashboard hidden from that user entirely

HighLevel's guide to dashboard permissions makes the override clear: give an Account Admin View-only access, and Account User permissions on that dashboard get pulled down to match.

Setting permissions for a new hire or a client's team works best in one order. Confirm the plan supports what they need, set the role at the right level, then layer the module toggles on top. Do it the other way around, and a "broken" permission usually turns out to be a plan limit nobody checked first.

Cover photo by Ivan S on Pexels