- Published
- Byline
- GoHighLevel Partners Editorial
- Filed under
- GoHighLevel Automation
HighLevel quietly replaced the old auto-approve model for Marketplace apps with a single toggle: Show only approved apps to sub-accounts. If your agency runs more than a handful of client sub-accounts, this setting now decides which third-party apps your clients can see and install — and getting the sequence wrong can uninstall an app your client is actively using, mid-workflow, with no warning to them.
This is the agency-side control, not the developer side. If you build and submit apps to the Marketplace, that process is unchanged. This article is about locking down what your sub-accounts can install from apps built by other developers — the governance layer, not the publishing pipeline.
Why HighLevel changed this
Before this update, any app that passed review and went public and live was automatically approved for every sub-account under every agency, with no review step for the agency in between. An agency running dozens of client sub-accounts had no consolidated way to see which third-party apps were quietly becoming available underneath them, or to stop one before a client found and installed it. That auto-approve behavior is the specific thing this update replaces — not a bug fix, a change in who gets to decide.
For an agency reselling GoHighLevel as white-label software, that matters more than it sounds. Every app a client installs is code with API access to that client’s contacts, conversations and calendar. An agency that can’t say which third-party apps are live across its book of sub-accounts can’t really answer a client’s data-handling question either.
Where to find it
From the agency view: App Marketplace in the left menu, then Manage App Permissions in the top-right corner. If App Marketplace isn’t visible in your left menu at all, it needs enabling from Labs first before any of the rest of this applies.
Inside Manage App Permissions you get a searchable, filterable list of every Marketplace app with its current approval state, plus a settings icon (top-right) that holds the global toggle itself. The whole screen was rebuilt for this update, which is also why the flow looks different if you used the old approval interface before.
Default approval behavior
Turning the toggle on does not start you from zero, and this is the part that’s easy to assume wrong. Per HighLevel’s own documentation, every app currently in public, live status is approved for your sub-accounts by default the moment you enable the toggle — including apps that pass review and go public afterward. The toggle changes who has to explicitly disapprove something going forward; it does not silently strip access from everything until you say otherwise.
That matters for planning: enabling Show only approved apps to sub-accounts does not, by itself, cut anything off. Your sub-accounts keep every app they currently have. You have to go in and disapprove specific apps afterward for the restriction to actually bite — the toggle is a gate you open selectively, not a wall that goes up automatically.
Who should actually turn this on
This is built for agencies where the sub-account count is high enough that nobody can eyeball what’s installed where — typically double digits and up, or any agency in a regulated niche (health, legal, finance) where a client asking “what third-party software touches my contact data” needs a real answer, not a guess.
A small agency running two or three sub-accounts it built and manages itself gets little from this beyond extra clicks: you already know what’s installed because you installed it. The toggle earns its keep when sub-accounts multiply faster than your team’s memory of what each one is running.
Bulk approval vs individual approval
Once the toggle is on, you manage state per app or in bulk from the same screen.
| Method | How it works | When to use it |
|---|---|---|
| Bulk | Filter to “Disapproved apps” (or “Approved apps”), multi-select, click Approve or Disapprove in the top-right corner, confirm in the modal | Rolling out an initial policy across dozens of apps at once, right after you turn the toggle on |
| Individual | Open a single app’s detail page, click Approve or Disapprove, confirm | Reacting to one client request, or reviewing a single new app before it reaches your sub-accounts |
Disapproving isn’t a one-click action you can walk back casually — HighLevel requires you to type CONFIRM in the action box before a bulk disapproval finalizes. That friction is deliberate, and the next section is why it needs to be there.
The trap: disapproval uninstalls the app immediately
This is the part every agency running client sub-accounts needs to know before touching this feature. Disapproving an app doesn’t just hide it from the Marketplace browsing view going forward. Per HighLevel’s own support documentation, it uninstalls the app from every sub-account where it was already installed, system-wide, as soon as you confirm.
Picture the ordinary way this goes wrong: an agency reviews its approved-apps list, sees a review-management or calendar-reminder app it doesn’t recognize on sight, disapproves it to be safe — and three client sub-accounts that were actively using it for appointment reminders lose that integration mid-week, with no notice sent to the client and no warning shown before the confirmation.
- If a client sub-account has that app wired into a live workflow, integration, or automation, disapproving it breaks that connection immediately — not on a grace period, not with a heads-up to the affected sub-account.
- Re-approving the same app later does not automatically reinstall it. HighLevel is explicit on this: a previously disapproved app that gets re-approved becomes available to install again, but it does not restore itself to the sub-accounts that had it before. Someone has to go reinstall it, per sub-account, by hand.
HighLevel’s own changelog notes recommend agencies review and clean up their current approved-apps list before flipping the global toggle on, precisely because of this. In practice: audit what’s actually installed and in active use across your sub-accounts first, decide your allowlist, and only then enable restrictions — not the other way around. Disapproving first and asking questions later is how a client’s live integration disappears without anyone deciding it should.
A related but separate control: hiding the Marketplace menu entirely
HighLevel also ships a second, distinct toggle worth knowing about alongside this one: agencies can hide the App Marketplace menu option from sub-account users completely. When it’s hidden, sub-account admins and users no longer see App Marketplace as a menu item at all — agency admins keep full access regardless of this setting.
This is a coarser tool than the approval toggle. Approval controls which apps are visible and installable while still letting sub-accounts browse and self-serve within your allowlist; hiding the menu controls whether sub-accounts can browse the Marketplace at all, turning every app request into a ticket to your team instead. Use approval when you want to offer a curated self-serve catalog; use the hide toggle when you want app installation centralized through your team entirely.
Whether hiding the menu also affects apps already installed, or only blocks new browsing and installs, isn’t stated in HighLevel’s documentation as of this writing — treat that interaction as unconfirmed and check the actual behavior in your own account before relying on it for anything client-facing.
A rollout checklist before you enable this
- List every Marketplace app currently installed across your sub-accounts, and which client is actively using each one — not which ones you remember installing.
- Decide your allowlist policy before touching the toggle, on paper if you have to, not while apps are already sitting in a disapproved state.
- Enable Show only approved apps to sub-accounts. Confirm your existing installs remain untouched, which per the default-approval behavior above they should.
- Disapprove only the apps you’ve confirmed are unused. If you’re not fully confident in the bulk flow yet, do the first pass one app at a time.
- Tell your team the sequence changed: a disapproval now takes effect immediately across every sub-account, not just in future installs.
- If a client needs an app reinstated later, remember re-approval alone won’t bring it back — you’ll need to reinstall it on that sub-account directly.
None of this is complicated once you know the sequence. The cost of skipping the audit step is a client’s workflow breaking with no warning, which is a worse conversation than the ten minutes the checklist above actually takes.
Frequently Asked Questions
Does turning on "Show only approved apps to sub-accounts" immediately remove apps from my clients?
No. Every app currently in public, live status is approved by default the moment you enable the toggle, so nothing is cut off automatically. You have to explicitly disapprove specific apps afterward for anything to actually be removed.
What happens to a sub-account if I disapprove an app it already has installed?
The app is uninstalled from that sub-account immediately, system-wide, with no grace period. Any workflow or automation depending on it stops working right away.
If I disapprove an app by mistake, does re-approving it bring it back?
No. Re-approving makes the app installable again, but it does not automatically reinstall it on the sub-accounts that had it before. You have to reinstall it manually, per sub-account.
Is hiding the App Marketplace menu the same as disapproving apps?
No, they're separate controls. Hiding the menu blocks sub-account users from seeing App Marketplace as a navigation item at all, while the approval toggle controls which specific apps are visible and installable when the Marketplace is accessible. Agency admins keep access to the Marketplace either way.
Can sub-account users approve or disapprove apps themselves?
No. Manage App Permissions is an agency-level control, reached from the agency view's App Marketplace menu. Sub-account users don't have access to the approval settings themselves.
We build your GoHighLevel account for you
CRM, pipelines, funnels, SMS and automation — configured for your business, not left for you to figure out.
- Setup (one-time)$850
- Ongoing (per month)$38.80
No obligation quote · reply within 1 business day
This site is independently operated and is not officially affiliated with, endorsed by, or sponsored by HighLevel LLC. We do not receive referral commissions — this is our own flat-fee implementation service.