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

A client cannot see a promised feature: investigate in order

Last materially reviewed 2026-09-27

Quick answerConfirm the workspace, agreed plan and two levels of access before changing billing, creating another user or granting broad permissions.
What to know

Capture the narrow symptom

Ask which task is unavailable, which workspace is open and what the intended user can actually see. A screenshot or precise description can be useful, but avoid collecting unrelated customer or payment data. Distinguish a missing menu from a visible feature that fails during use. Those observations lead to different investigations and should not be collapsed into the phrase account broken.

What to know

Compare with the agreed matrix

Check whether the feature was promised in the current plan and whether that version is effective yet. Then inspect subaccount feature access and the person’s user permissions. HighLevel documentation describes both levels. If the plan sheet and configuration disagree, resolve that mismatch through the approved process; do not tell the client to purchase an upgrade simply because it is the easiest visible button.

What to know

A fictional wrong-workspace example

A user belongs to two similar workspaces and opens the older one. The new package may be configured correctly elsewhere. Creating another identity or changing permissions in the wrong workspace would add confusion without addressing the cause. Confirm identifiers and context before editing anything. This example illustrates the diagnostic order and is not evidence of a particular HighLevel incident or a guaranteed fix.

What to know

Escalate only the unresolved part

If the identity, plan and permissions are correct but the task remains unavailable, preserve the specific observation and ask the provider a focused question. Include necessary references through an approved support channel, not secrets. Record the issue as unresolved until the intended task works. A changed setting or a support acknowledgement is not by itself proof that the client has received the feature promised in the package. Finish the investigation note with the exact missing task and the next responsible party. Do not label the entire platform unsuitable or the client incorrectly configured while the underlying cause remains unverified.

Continue when useful

Next: Build a client-plan feature matrix

Map each promised feature to actual subaccount access, a responsible user and a verification step.

Open Build a client-plan feature matrix →

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