Users & Permissions

We need the ability to set a team member as Admin on some subaccounts and as a User on other subaccounts. Right now, if I set a team member as an Admin on one subaccount, it changes them to an Admin on all subaccounts.

The ability to control who has access to phone number changes including recording, assigning, forwarding, etc. is needed. or the ability to track who made the change.

Please add the ability to resend the Welcome Email to an existing user in a sub-account without deleting and recreating the user.

It's really annoying when you've setup your personal work flow for contacts, opportunities, tasks etc only to then lose all those filters and have to re-apply them ALL the time. Especially annoying when the "default" filter (like "open" in pipelines) is the opposite of what you need. "Views" should be saved automatically server-side meaning if someone logs in from anywhere on any device, they still have the same settings. (and the ability to have different views could be useful too, but the starting point would be to make all filters and sorting server-side.)

Currently, users must be granted Admin privileges to access and manage URL Redirects. This also provides access to the full Settings area and other administrative controls, exposing functionality beyond what is required for their role. We need a dedicated, granular permission that allows users to manage URL Redirects without granting Admin rights or access to the Settings section. Introduce a standalone permission (e.g., “Manage URL Redirects”) that enables users to: Create, edit, and delete URL Redirects View existing URL Redirect configurations

I came across this issue as I have a user that already exists in my system through someone else's sub-account and now they want their own account but they purchased a plan that gives them fewer permissions but I can't remove features from their profile without it affecting the other subaccount they are in. This is definitely a limitation for my (and probably other's) use cases.

Currently, when a user is assigned to multiple sub-accounts in GoHighLevel, they must share the exact same permission set and access level across all of them. This limitation makes it difficult to manage users who need different roles or visibility scopes per sub-account — for example, an admin role in one client account, but only a restricted “view-only” role in another. Proposed Improvement: Enable administrators to assign unique permission levels per sub-account for the same user. Each sub-account should have its own role and permissions configuration, independent from the global user profile. Why this matters: Agencies with multiple clients or brands often have the same team members working across several accounts, but in different capacities. It would improve security, flexibility, and operational efficiency by removing the need to create duplicate users with different email addresses. Aligns with enterprise-level user management standards (similar to role-based access control per workspace). Example Use Case: A marketing manager could have full access to automation and pipelines in one client sub-account, but only reporting and conversation view access in another — all under the same login.

We need the ability to set user role permissions on a per-subaccount basis. Example: In Subaccount A, remove access to Automations, Forms, Sites, Funnels, and Surveys. In Subaccount B (and others), keep full access to these features. Currently, changing role permissions affects all subaccounts a user is part of, which limits flexibility for agencies managing multiple clients and internal teams. Benefit: This would allow granular access control, improve security, and prevent unnecessary workarounds like removing users from certain subaccounts entirely. Request: Please add the option to manage permissions individually per subaccount without impacting other subaccounts.

Description: Currently, managing permissions for the Notes section (on contacts, opportunities, etc.) lacks the necessary granularity for effective team management and data protection. To better manage diverse teams and safeguard important information, we require finer, role-based controls over what users can do with notes. --- Problem & Use Case: Different user roles within our business require different levels of access to notes. For example: We need the ability to assign Create Only permissions to certain roles (like VAs or entry-level staff) so they can add new information without the risk of accidentally editing or deleting crucial historical notes logged by senior staff or other team members. Other team members might need the ability to Create/Edit notes to update information as situations evolve, but should still be restricted from deleting notes entirely to maintain record integrity. Full Create/Edit/Delete permissions should be reservable for administrators or specific trusted roles. Without these distinct levels, we either grant too much access (risking accidental data loss or unauthorized modification) or restrict users too much, hindering productivity. This also makes it harder to maintain data integrity and accurate historical records. --- Proposed Solution: Please implement the following distinct permission levels that administrators can assign to users specifically for the Notes section: Create Only : User can add new notes but cannot modify or delete any existing notes. Create/Edit : User can add new notes and edit existing notes, but cannot delete notes. Create/Edit/Delete : User has full control – allowing adding, editing, and deleting of notes they have access to view. --- Benefits: ✅ Improve security and data integrity by limiting modification/deletion rights. ✅ Prevent accidental loss of important client history or internal communication. ✅ Empower administrators to configure user access precisely according to job responsibilities and trust levels. ✅ Enable more secure, effective, and clearly defined team collaboration within HighLevel. Implementing these granular permissions would be a valuable improvement for managing teams and protecting data within the platform.

I got to know about GHL CRM as we implemented that in my company. I loved it so much that I signed up for the agency account and have my MCTB site up already. However, as I learnt more about how the agency and subaccount relationship works and the user permissions are setup, I am really questioning whether to continue offering this service to other clients. I've noticed the agency owners by default are privy to their subaccounts complete data set, i.e. their customers, addresses, costs, etc. In other words, if I run an operational business alongside my GHL agency and I attract one of my competitors to signup with my agency (unbeknownst to them that I own the other business as well), I can run away with their entire client set and start poaching. Or, if one of your subaccounts is a medical clinic or in a highly sensitive sector, this is quite a serious breach! The decision to turn off the user permissions are left to the good graces and judgment (or ethics) of the agency owner. Personally, I find this awfully troubling & deeply concerning, especially in today's heightened privacy and data security environment. This has huge data security, privacy breach, ethical issues legal risk written all over it. Unless the client specifically grant’s you access to their data, you MUST NOT have auto access to their lifeline! I like GHL and want them to be a huge success. But this issue is more than just me or you. It’s the overall principle that we need to work out for the betterment of GHL, ours, and most importantly Clients. I have raised this issue with multiple different people from GHL, but seems like they aren't too bothered with that. here's a link to my FB post about the same: https://www.facebook.com/groups/594608437665362/user/1471297944