Users & Permissions

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.

Create option in Agency company settings for agency admins/owners to turn on or off that is: "Allow all users to toggle light / dark mode individually." That way, this option is off by default, giving all GHL agencies time to write code for whichever mode they've not got code for. Turn current Custom CSS box in Agency company settings into "Custom CSS for light mode" ... and then "add Custom CSS for dark mode" right below it. Provide light/dark mode toggle for all users under "My Profile" or in upper right hand corner, similar to the light/dark mode toggle used in Community feature. Only make available if option in point #1 (above) is turned on by agency admin/owner.

Ability to track email & sms sent as internal notifications seamlessly within the highlevel platform.

It would be helpful to have the read only option for pipelines like you do for the workflows. This would prevent regular users from accidentally messing up the pipeline which controls, almost everything in the automations. It does not serve, in most cases, to turn off Opportunities completely. Regular users need access to Opportunities, but only qualified Admins should access and edit a pipeline.

Hello everyone, This feature is urgent and essential for many clients! We need to be able to manage availability in more detail from the user profile than is currently possible. We should have the ability to have a calendar in which we enter our availability day by day, instead of entering recurring availability for each week, as is currently the case. Many clients have employees with varying availability, and this is very frustrating for them. Furthermore, to make it even more user-friendly, add the ability to choose availability in the calendar by range. Similar to when we indicate the outbound and return dates for a trip. Example: March 15th to March 23rd, available from 9 a.m. to 5 p.m.

When setting up the user we would like to see a 2nd field for email from. The current "user email" for login and where a user can receive notifications in there normal inbox would remain. The 2nd field where outbound emails from GHL will be sent. This will allow prospects to receive an email from LC/Mailgun that looks personalized and not a system looking email (on the behalf of).

Requesting a feature that allows an admin to temporarily view the system exactly as a specific user or role. This would streamline permission troubleshooting, confirm visibility settings, and remove the need for test accounts or manual permission switching.

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.

Description There is a critical platform vulnerability that allows user records, including Agency Admin accounts, to be overwritten with data from unrelated contacts or sub-account users. This includes overwriting authentication fields such as phone numbers used for MFA and 2FA. This can occur during imports, cross-scope updates, API activity, or system processes. Audit logs show the update as if the admin performed it, even when they did not. This leads to lockouts, loss of access, inaccurate audit attribution, and no safeguards to prevent the overwrite. Problem Summary An Agency Admin authentication phone number was replaced by a sub-account user’s number. The system allowed this with no conflict checks, duplicate detection, or permission validation. Audit logs incorrectly attributed the change to the admin. The admin was locked out due to 2FA failure. This shows that lower-scoped user data can overwrite higher-privileged accounts. Current safeguards only protect contact records, not user records. Why This Must Be Addressed Authentication fields for Agency Admins should not be changeable by imports, automation API activity, or sub-account processes. Overwriting the login phone or the login email is a security risk. Audit logs cannot currently distinguish between manual actions and automated system updates. This vulnerability can lock out administrators, corrupt user identity data, and undermine confidence in platform security. Agencies with multiple sub-accounts and frequent imports are most at risk. Proposed Solution Protect authentication fields, such as login email and MFA phone, so they cannot be overwritten by imports, automations, or API calls across scopes. Require explicit re-authentication when authentication fields are changed. Prevent sub-account user data from updating the agency-level user records. Improve audit logs to clearly distinguish manual actions, import automation, and system-generated updates. Add conflict detection and duplicate warnings for user-level data, similar to contact protections. Provide a setting allowing admins to lock authentication fields from automated updates. Impact Without This Feature Agency Admins can be locked out due to unauthorized MFA changes. Data integrity is compromised when lower-scoped records overwrite high-privilege accounts. Support teams cannot accurately determine the cause due to vague audit logs. Agencies cannot safely use import workflows or API integrations without risk. Overall trust in the platform security model is weakened. Summary HighLevel needs stronger security controls to prevent cross-scoped overwrites of user data, especially authentication fields for Agency Admins, Agency Owners, and other privileged roles. Authentication data should be protected, audit logs must clearly identify the true update source, and imports or system processes must never overwrite admin identity fields.