Independent HighLevel affiliate publication. We may earn a commission if you buy through links on this page, at no extra cost to you.

Practical guide

Feature access and user permissions are separate checks

Last materially reviewed 2026-09-27

Quick answerCheck what the subaccount includes before changing what an individual user may do.
What to know

Name the two questions

First ask whether the feature belongs in this client’s software package. Then ask whether the particular person should be able to use it. Mixing those questions can lead to unnecessary plan changes or excessive user access. HighLevel’s current permission documentation describes separate subaccount and user levels; our recommendation is to record the intended result before editing either.

What to know

Create a small role record

For each role, identify the task, minimum required capability, approver and review date. A client administrator and a temporary service operator may need different permissions. Avoid using an all-access role as the default cure for a missing menu. Access should follow an actual responsibility, not the convenience of avoiding a few minutes of investigation.

What to know

A fictional diagnostic case

A client teammate cannot find a feature. Confirm the correct workspace and plan first, then inspect the relevant user role. If both appear appropriate, capture the observed behavior and escalate the specific issue rather than creating a second identity. Do not conclude that a missing menu proves a billing failure; it may have a different cause. This case is a reasoning example, not product-test evidence.

What to know

Check the result without overreaching

After an authorized permission change, have the intended person verify the relevant task and confirm that unrelated capabilities were not added. Preserve the earlier state for investigation. Review temporary access when its purpose ends, but do not remove an owner until continuity is arranged. Avoid sharing credentials between people; a clear role record is more useful than a shared password that obscures who performed an action. Write down the intended task before editing a role and compare it with the observed result afterward. This small discipline helps prevent a narrow support request from becoming an unnecessary access expansion.

Continue when useful

Next: A client cannot see a promised feature: investigate in order

Confirm the workspace, agreed plan and two levels of access before changing billing, creating another user or granting broad permissions.

Open A client cannot see a promised feature: investigate in order →

Sources used for this page

These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.

  1. Subaccount feature permissions — Merchant documentation · help.gohighlevel.com · Merchant-controlled · checked 2026-09-27