This is so critical for agencies to be able to give these types of permissions to protect their business. Obviously when we bring on support we want to be able to limit access to some things, but have our staff still be able to access new sub accounts to onboard them properly. Having to add these sub accounts to their permissions manually isn’t something an agency owner has time for. There’s needs to be an easy way to restrict sub accounts (our Snapshots) so people dont accidentally edit them. Waiting for this to happen as much as everyone else.

This should have been done many moons ago. Please implement as quickly as possible as it hinders agencies from scaling their business.

Just like there is an ability to limit agency users at the subaccount level - we should be able to align the snapshots that are associated with subaccounts as a permission also. Agency users who only have access to a particular subaccount/s should not be able to view, edit or push snapshots linked to other subaccounts.

@coreplatform Can we please hide Activity log for users - dont need them seeing all the forms, surveys, websites, funnels, that we have built if they are on sales. They are not part of the marketing team so do not need to see that information.

It’s incredibly frustrating to see that, despite years of requests and countless threads from agency owners and users, we still don’t have truly granular permissions at the agency level. Recent updates, such as the Permissions Update & User Management and Enhanced User Permissions in Calendars, were meant to provide better control, but they fall far short of what’s actually needed.

For example, the Permissions Update: https://ideas.gohighlevel.com/changelog/permissions-update-user-management still requires someone to be an Admin at either the agency or account level in order to grant "Manage User" permissions. How does this solve the problem? If the goal was to prevent unauthorized user access, all that was needed was a simple change from Admin to User—problem solved. Instead, we’re still stuck with a system where permission control is all or nothing.

The same goes for the Calendar Permissions update: https://ideas.gohighlevel.com/changelog/enhanced-user-permissions-in-calendars . Yes, users can now be assigned separate View and Manage permissions, but in order for this to work, they still need full Account Settings access. How does that make sense? This would be a huge improvement only if it didn’t require giving access to everything.

I’ve even reached out to support regarding these issues, and they agreed that the system isn’t as flexible as it should be—yet their response was that there’s nothing they can do. It’s unacceptable that after so much time, we still can’t assign permissions at a truly granular level for agency users, nor restrict even the most basic access settings properly.

This has been an ongoing request for years. At what point will the updates actually reflect what agency users need?

There should be an option that can allow an agency User to add additional users/admins to subaccounts.

how do we restrict permissions to the Agency dashboard for Agency Admins?

Found this idea because I can't grant permission to an agency user to SEE (at the agency level) the Template Library or even ADD Templates (from the sub account level) to the Agency Template Library. Granting the user Admin access just for working with templates is not a suitable solution given everything that comes with Agency Admin access.

To add to this:

As an agency owner, I dont actually want to see Subaccount data/contacts, that is a privacy concern and would much rather those contacts are redacted / only show up as "ID" so we cannot see their data, even if this is a toggle that the Subaccount Admin can adjust and toggle off if they dont care. But we are having trouble selling GHL due to this privacy concern.

There should be a way to restrict agency admin or the user from seeing all the tabs in the agency view. We can limit the access of agency users or the admin to what exactly they can see in the agency.