Users & Permissions

I need a way to limit the number of employees that a sub-account owner can add to their account AND even prevent a sub-account owner from adding employees all together. I would also like the option to charge an incremental amount to the sub-account owner by how many employees they add. Even further, by including these settings in a snapshot, it would help automate the process of granting user permissions based on the SaaS plan or snapshot selected. By adding more granular control of 'User Permissions' within various sections and items under, this could be achieved. For example, the User Permissions for Settings could have sub settings to check on or off each of the items under each category. For example within Settings, we would have a toggle for each of the following items: MY BUSINESS Business Profile My Staff Pipelines BUSINESS SERVICES Calendars Phone Numbers Reputation Management Profile OTHER SETTINGS Custom Fields Custom Values Domains Media URL Redirects Integrations Email Services Conversation Providers Tags Labs Audit Logs

Enhance data security and privacy by adding a [Support] role to the current limited roles of [Admin] and [User], and giving Agency Admins the ability to hide/unhide certain fields and functionalities for said [Support] role. Generally speaking, [Support] staff design, implement and debug solutions only, and do not need access to end-clients' private data like [First Name], [Last Name], [Name], [Contact Number], [Email], [Calendar] and [Address] etc, and rich functionalities like [Import], [Export] CRM data. What [Support] staff need are certain functional fields like [ContactID], [Calendar.EventID], [PaymentID] etc and the ability to access as-needed functionalities like [Automation], [AI] etc and when bugs are reported and specific needed modules/ data may be selectively shared. In other words, [User] role is for our clients and their users, [Admin] role is for our agency's OIC and our clients' OIC, and [Support] role is for our agency's and/or external 3rd party backend developers. Such a demarcation will allow for greater scalability for agencies who would like to engage external/ remote backend help and have chosen not to do so due to data privacy considerations.

I would like to suggest allowing the use of the same user account across different sub-accounts, with the option to assign different roles and permissions for each.

Need users to be able to see data, but only edit their own contacts.

I think having a test user/contact/account that can be linked to a test GHL test phone number and email (only for test purposes of course) without having to provide your own personal information will be helpful for testing purposes. Or if someone has "test" in the contact or tagged as "test contact" then that will automatically remove them from automations unless "test workflow" is utilized. Because my work email is getting bombarded with all my clients/sub-accounts emails that I would love to support but clutters my work environment. There has to be a way to make testing more efficient.

We need more comprehensive audit logging across the platform for compliance, accountability, and troubleshooting. Current audit logs only cover limited modules (users, funnels, calendars, listings, etc.) but do not provide visibility into several critical areas. Requested Enhancements: Login Trails: Full history of user logins/logouts with timestamps, IP addresses, and device/browser details. Billing Changes: Track when payment methods, subscription tiers, or billing settings are updated, and by which user. Feature Toggles: Record whenever sensitive features are enabled or disabled (e.g., call recording, A2P compliance settings, calendar syncs). Retention: Extend audit log history beyond the current ~60-day limit, or allow configurable retention. Export & API: Ability to export logs (CSV/PDF) and query via API for compliance and external reporting. Use Cases: Security audits (detect suspicious logins or unauthorized changes). Legal/compliance (billing disputes, call recording opt-in/out tracking). Operational accountability (knowing which team member made a change). This would align HighLevel with enterprise-class CRMs and help agencies maintain proper compliance records for clients in finance, healthcare, and regulated industries.

Currently, we are only allowed just two main user roles—Admin and User. In our business model, we have sales reps who manage sensitive, high-net-worth clients. Some workw exclusively with these clients, and we need to ensure that only he and the admins can view and manage those particular contacts. On the other hand, we also have a broader group of salespeople who handle general incoming leads. These leads go into a user we created called "house account" and then i have an automation that assigns new contacts to that user. In that same automation, i add all the sales staff as contact followers so they can still be assigned tasks and see acitivy. While this workaround helps us, it also leads to intermittent issues and additional complexity. For instance, we recently had a scenario where a contact assigned to the house account had a task created that was assigned to a sales person (different user), but due to permission limitations, when the salesperson with the assigned task viewed his tasks screen from the contacts module, the associated contact field wasn’t visible to that rep. So there was no actionable way to conduct that task. Somehow that was eventually resolved on its own. Currently, contact followers cant see "house account" conversations, which created a big problem with one of our clients. It highlighted how fragile these workarounds can be. In other words, we’re relying on automations to manage workflows that would be much simpler if we had more nuanced user role permissions built into the platform. We are also sensitive to protecting a certain salesperson's contacts and have had staff in the past reassign contact ownership to themselves. Assigning the sales staff as followers allows them to see the contact, but not change the ownership, which currently works as a solution, but it is creating all the problems that i mentioned above. We believe that adding more granular permission controls, or allowing subaccounts to create their own user roles with more options for permissions with contact would benefit many businesses like ours. It would reduce the need for these complex workarounds and ensure a smoother experience.

Small business owners also employ people and provide salary to them. If we add the HR features such as employee timesheet tracking and payroll processing for team members in Go high level, then our platform will be even more appealing to small business owners who wants to use our platform.

For an agency owner to transfer a sub account it requires the agency owner to put in their password, but if the agency owner is using SSO, it requires that the agency owner go and set a password rather than use SSO to authorize the transfer. We need to be able to authorize the transfer with SSO rather than have to create a password.

Whilst the recent enforcement of 2FA (via email) is a welcome addition to the security of High-Level, email based 2FA is unfortunately one of the least secure 2FA methods. So, please add more 2FA options. Including at a minimum TOTP codes (a global standard) that people can use through whatever TOTP App they use. (E.g. Authy, Duo, Google Authenticator, Microsoft Authenticator etc). And at the same time, please: Allow an agency to select what 2FA options they will allow to be used across their clients. Allow Admins of a sub-account to also have this level of functionality to select what 2FA options users in their Sub-Account can use IF the Agency gives it to them.