HighLevel Triples Sub-Account Feature Permissions to 80+, but the Defaults Stay Open

August 13, 2026. HighLevel expanded sub-account feature permissions on August 11, taking the number of features an agency can switch on or off for a client from roughly 30 to 35 up to more than 80, and reorganising them into a three level tree of Category, Module and Feature. The coverage story is the one that will get written everywhere. The more useful reading is in the two sentences underneath it, because between the carry-over clause, the wording of the enforcement promise and the plan tier that gates the only scalable way to apply any of it, this release hands most agencies a much larger set of switches and no practical way to flip them this week.

What HighLevel actually shipped

1. Feature permission coverage rose from around 30 to 35 features to more than 80, per HighLevel's changelog entry of August 11, 2026.
2. Permissions are now grouped as Category, then Module, then Feature, so an entire module can be toggled at once instead of hunting through a flat list.
3. The same structure appears in all three places permissions are set: on a sub-account directly, on a SaaS plan, and when assigning or managing a plan for a client.
4. Existing permission settings were carried over automatically, and HighLevel states that no sub-account or SaaS plan loses access to a feature it already had.
5. SaaS plan level configuration is limited to agencies on Pro plans. Sub-account level configuration is available to every agency.
6. Bulk actions for managing permissions across sub-accounts are described as coming, expected the following week, which means they were not available at release.

The carry-over clause and the new switches

Read the coverage number and the carry-over promise together and they resolve into something specific. If control went from roughly 30 to 35 features to more than 80, then somewhere close to 45 to 50 features became controllable for the first time on August 11. By definition none of those had a prior setting, because there was no switch to set. So a carry-over that guarantees no sub-account loses access to anything it already had is a carry-over that leaves the entire newly covered surface exactly as it was before, which is visible to the client.

That is the correct engineering decision. Silently hiding 45 features from every client account in the world overnight would break more agencies than it helped. But it means the release did not tighten anything. It added switches and left them in the permissive position. An agency that reads the headline, assumes its clients are now locked down more thoroughly, and moves on will be in exactly the state it was in on August 10, with a longer settings page.

What the enforcement promise admits

The Why It Matters paragraph is worth reading as a statement about the past rather than the future. It says agencies who whitelabel need to be sure that when a feature is turned off it is actually off, and lists more reliable enforcement among the things this update delivers, so that toggled-off features stay hidden from sub-accounts.

Enforcement being made more reliable is a claim that it was previously less reliable. HighLevel does not say which features leaked, or how, or for how long, and it would be wrong to speculate. What can be said without guessing is the practical instruction that follows: if you turned a feature off before August 11 and you have never logged in as a client user to confirm it was hidden, the vendor's own framing is a reason to check rather than assume. A toggle in the off position is a setting. Whether the client can reach the feature is a behaviour, and the two are only the same thing when enforcement works.

The tier gate, and why it decides your effort

The distinction between the two configuration levels is where this becomes a budgeting question. Per HighLevel's pricing page, the plans are Starter at 97 dollars a month with 3 sub-accounts, Unlimited at 297 dollars a month with unlimited sub-accounts, and Agency Pro at 497 dollars a month, which is the tier that carries SaaS Mode and automated sub-account creation.

SaaS plan level permissions sit on Pro. That is the level that scales, because a SaaS plan is a template: configure the tree once and every client on that plan inherits it, including clients who sign up later. Sub-account level permissions are available to everyone, and they are per account, which does not scale at all.

The awkward case is Unlimited. At 297 dollars a month an agency can run an unlimited number of sub-accounts but can only configure permissions one sub-account at a time. The plan sells volume and the permission model prices the template. An agency with 40 clients on Unlimited is looking at 40 manual passes over a tree that just grew past 80 items, repeated for every new client, with no way to save the result as a default.

Bulk actions do not exist yet

HighLevel flagged bulk permission management across sub-accounts as expected the following week. As of this article's publication that is a roadmap item, not a feature. The sequencing matters more than it looks. The release enlarged the surface first and shipped the tool for applying it at scale second, so the gap between those two dates is a window in which the rational move for a high client count agency is to wait rather than to start clicking.

There is one exception. If a specific feature is one you have a contractual or compliance reason to keep away from clients, that is not a wait-for-bulk item, that is a today item, and it should be handled per sub-account now regardless of how tedious it is.

The permission chain, and a doc that has not caught up

The underlying model has not changed and is worth restating because it constrains everything above. HighLevel's SaaS Configurator documentation, in SaaS User Level Permissions Vs Sub-Account Level Permissions, states that a user cannot have more permissions than the sub-account level permissions allow. Sub-accounts created through SaaS Mode inherit their permissions from the feature set of their plan in the SaaS Configurator, and the user account generated at signup inherits from there. Plan sets sub-account, sub-account caps user.

That article was last modified on 23 February 2024, and it describes reaching the toggles through the Sub-Accounts tab, the three dots menu, Manage Client, and an Enable and Disable Products section. That is the flat list the changelog just replaced. The ceiling rule it documents still holds. The navigation it documents is two years old. If you hand this doc to a team member as the instruction for configuring a client, they will be looking for a screen that no longer matches what is described.

What it means for operators

The practical order of work, for an agency that whitelabels HighLevel and bills clients for it:

1. Write down what clients should not see before opening the new tree. Source that list from your own scope of work and your client contracts, not from the settings page, or you will end up rationalising whatever the defaults happen to be.
2. Start with the features that became controllable on August 11, because those are the ones with no prior decision behind them. Everything that existed before carries a setting somebody once chose. The new ones carry nothing.
3. If you are on Agency Pro, do the work once at SaaS plan level and let new clients inherit it. Configuring Pro at sub-account level is paying for the template and then not using it.
4. If you are on Unlimited with a meaningful client count, handle anything compliance related now and hold the rest until bulk actions land, then do it in one pass.
5. Verify by logging in as a client user rather than by looking at the toggle. Given how the enforcement improvement is worded, the setting and the behaviour are separate claims and only one of them is visible from the agency view.
6. Update your internal runbook. The official doc for this model predates the new structure, so whatever your team follows internally is now the more accurate of the two.

For agencies who sell HighLevel as their own product, permission scope is not a settings chore, it is the product boundary. It decides what the client believes they are buying, which features can be sold later as an upgrade, and how much of the platform's surface area your support team is implicitly on the hook for. Getting the tree right once at plan level is worth more than getting it right forty times. If you are packaging HighLevel into a whitelabel offer and want the plan tiers, permission scope and rebilling to line up with what you actually charge, that is the work our GoHighLevel services team does, and the same boundary questions come up whenever we help a founder launch a SaaS product on top of someone else's platform.