Users & Permissions

Introduce Enterprise-Grade Granular Permissions: Field-Level, Record-Level, Resource-Level & Action-Based Access Control
The Problem GoHighLevel needs a much more granular user permissions system to support enterprises, agencies, franchises, educational institutions, and organizations with complex teams. Currently, module-level permissions are too limiting. Organizations need to control exactly what users can see, create, edit, delete, publish, export, or manage—not just whether they can access an entire module. Proposed Solution Introduce granular permissions across five levels: 1. Field-Level Permissions Allow administrators to control access to individual fields within Contacts, Companies, Opportunities, Appointments, Products, Services, Invoices, Estimates, Payments, Custom Objects, and all other record-based modules. For each field, support: View Create/Set Value Edit Clear/Delete Value Export Mask Sensitive Data No Access Example: A sales agent can view and edit a contact's name, email, and phone number but cannot see revenue, customer lifetime value, or confidential internal notes. A manager can access those additional fields. Restricted fields must remain inaccessible through the UI, APIs, exports, reports, search, and integrations unless explicitly authorized. 2. Record-Level Permissions Allow administrators to determine which specific records users can access. Supported access scopes should include: All records Own records Assigned records Team records Sub-team records Specifically shared records Records matching custom conditions No records Example: A salesperson sees only their assigned contacts, while a department manager sees contacts belonging to their entire team. 3. Resource-Level Permissions Allow permissions to be assigned to individual resources, including: Websites and Funnels AI Studio Projects Workflows and Automations Calendars Forms and Surveys Pipelines Dashboards and Reports Email/SMS Templates Documents and Media Courses and Communities Custom Objects Example: Website permissions should support all of the following scenarios independently: User can view all websites but cannot edit any. User can view all websites but cannot create new ones. User can create their own websites but cannot view other websites. User can edit Website A, view Website B, and have no access to Website C. User can create and manage their own websites but cannot edit existing websites owned by others. User can view only specifically assigned websites. User cannot create websites but can edit selected existing websites. Creating a resource should NOT automatically grant access to every existing resource within that module. Functionality & Action-Based Permissions Allow administrators to control individual actions inside each module. Example: Websites and Funnels View Create Edit content Edit design Edit settings Publish/Unpublish Delete Duplicate Manage domains Manage SEO Manage integrations Share/Manage collaborators A designer could create and edit websites but not publish them. Example: Workflows View Create Edit Activate/Deactivate Delete Edit triggers/actions View execution logs Manage settings An employee could build workflows without being allowed to activate them. Example: Invoices View Create Edit drafts Send Void Issue refunds Apply discounts Export View payment details A finance assistant could prepare invoices without permission to send them or issue refunds. These action permissions should be available throughout HighLevel, wherever applicable. 5. Centralized Permissions Board Introduce a permissions management interface supporting: Organization, Team, Sub-Team, Role, and User permissions. Permission inheritance and overrides. Reusable roles and permission templates. Explicit Allow/Deny rules. Individual resource permissions. Field-level permissions. Bulk permission editing. Temporary permissions. Audit logs. Permission previews showing exactly what each user can access. Administrators should be able to assign permissions to an entire team or sub-team while maintaining the ability to override permissions for individual users. Important: Permissions Must Apply Everywhere Permissions must be enforced consistently across the CRM, mobile applications, APIs, reports, exports, workflows, AI Studio, AI agents, and third-party integrations. Restricted information should not become accessible through another interface or endpoint. API Support Provide APIs to create and manage roles, teams, permissions, resource access, field-level restrictions, record ownership, and user access. Developers should also be able to retrieve a user's effective permissions to build custom interfaces that respect HighLevel's authorization system. Why This Matters A large organization may have hundreds of employees working within the same CRM but requiring completely different access levels. A marketing designer should be able to create websites without accessing confidential projects. A salesperson should access customer contact details without viewing sensitive financial information. A manager should oversee departmental records without automatically accessing every department. HighLevel should support these scenarios without forcing organizations to create separate accounts, duplicate data, or rely on external software. The Opportunity This would make GoHighLevel significantly more competitive as an enterprise platform and enable developers to build sophisticated, industry-specific applications on top of its existing CRM infrastructure. The goal is simple: Give administrators precise control over WHO can access WHAT, WHICH specific records or resources they can access, and exactly WHAT ACTIONS they can perform. Granular permissions should be a foundational capability throughout the entire HighLevel ecosystem.
0
·
New Feature
Add Teams, Sub-Teams & Group-Based User Permissions
Category: CRM / Team Management / User Permissions The Problem GoHighLevel needs a more scalable way to organize users and manage permissions, especially for agencies, franchises, schools, and enterprise organizations with large teams. Managing permissions individually for every user becomes increasingly difficult as organizations grow. There should be a way to organize users into Teams and Sub-Teams , assign permissions at the group level, and automatically apply those permissions to members. Proposed Solution Introduce a hierarchical Team Management system that allows organizations to create Teams, Sub-Teams, and nested organizational structures. Teams & Sub-Teams Allow administrators to: Create unlimited Teams and Sub-Teams. Organize teams into parent-child hierarchies. Assign users to multiple teams. Designate Team Leaders and Managers. Move users between teams. View the organizational hierarchy through a visual organization chart. Example Structure: Company Marketing Department - Social Media Team - SEO Team - Paid Advertising Team Sales Department - Inbound Sales - Outbound Sales Operations Department - Customer Support - Project Management 2. Group-Based Permissions Allow administrators to assign permissions directly to Teams and Sub-Teams rather than configuring every user individually. Requested Features: Team Permissions: Assign access to CRM modules, features, and records at the team level. Permission Inheritance: Sub-Teams can inherit permissions from their parent Teams. Permission Overrides: Allow authorized administrators to customize permissions for specific Sub-Teams or users. Role-Based Access Control (RBAC): Create reusable permission roles such as Manager, Editor, Viewer, and Administrator. Multiple Team Memberships: Support users belonging to multiple teams with clearly defined permission resolution rules. Bulk Permission Updates: Change permissions for an entire team simultaneously. Custom Object Permissions: Control which teams can create, view, edit, or delete specific Custom Objects and records. Record-Level Access: Restrict records by assigned user, team ownership, or other defined access rules. Team-Based Resource Access Allow administrators to grant Teams and Sub-Teams access to specific resources, including: Contacts and Companies Custom Objects and associated records Opportunities and Pipelines Calendars and Appointments Conversations and Inboxes Workflows and Automations Websites, Funnels, and AI Studio Projects Forms and Surveys Documents and Media Reports and Dashboards Permissions should support granular actions such as View, Create, Edit, Delete, Manage, and Share , wherever applicable. 4. Centralized Permissions Board Introduce a dedicated User & Team Permissions Board where administrators can manage access across the organization from one interface. The board should include: A permissions matrix showing Teams, Sub-Teams, Roles, Users, and their access levels. Bulk permission editing. Search and filtering. Inherited versus directly assigned permissions. Effective permission previews showing exactly what each user can access. Permission change history and audit logs. The ability to copy permission configurations between teams. 5. Enterprise Features Team-Based Record Assignment: Assign contacts, opportunities, and Custom Object records to teams rather than only individual users. Team-Based Workflow Automation: Trigger workflows when users join, leave, or change teams. Automatic Permission Provisioning: New team members automatically receive their team's permissions. Temporary Access: Grant permissions for a specified period. Team-Specific Dashboards: Display relevant information based on team membership. API Support: Create, update, retrieve, and manage Teams, Sub-Teams, memberships, and permissions programmatically. Why This Matters Consider a university using GoHighLevel: The university may have multiple campuses, departments, faculties, and administrative teams. Each department requires different access to student records, applications, communications, workflows, and operational data. Without hierarchical team management, administrators must manually configure permissions for hundreds or thousands of users. With Teams and Sub-Teams, administrators could manage permissions for entire departments in seconds. The same applies to multinational enterprises, franchise networks, healthcare organizations, agencies, and other complex organizations. The Opportunity for HighLevel This would help transform GoHighLevel from a CRM designed primarily around individual user permissions into a platform capable of supporting complex enterprise organizational structures. It would reduce administrative overhead, improve security, simplify onboarding, and make HighLevel significantly more scalable for large organizations. The ultimate goal: Allow organizations to structure their teams exactly as they operate in the real world, with centralized, hierarchical, and granular permission management across the entire HighLevel platform.
0
·
New Feature
Allow Multiple Gmail Sync connections and Fix it applying to ALL of my assigned Subaccounts
I bet you didn't know... When you connect Gmail Sync in your user profile from within your Subaccount ... it actually is integrating your Gmail Sync into your USER PROFILE, which is applied to ALL of your Subaccounts. This means that if Subaccount-A and Subaccount-B both have bob@example in CRM Contacts, and your cliff@domainA emails him, Subaccount-B will also display your email to him in the conversation history. Yikes for security! Available Workaround: create one user account for each Gmail you want to connect Your primary/day-to-day user account cannot have any email sync attached Create a new user for each Gmail you want to connect Gmail but will never actually log in to Example: cliff@agency is the day-to-day user (do NOT connect ANY Gmail), create GHL user info@agency and create GHL user cliff@realestate Assign info@agency user to Subaccount-A (Agency's subaccount) and assign cliff@realestate user to Subaccount-B (Realtor subaccount) switch login to those users, connect your Gmail at their subaccount > My Profile, then switch back to your day-to-day/actual agency user account. You may still assign yourself to a subaccount if desired, just don't connect your Gmail. Why this is NOT viable: now you have clutter in your users list (assign Contact to user, schedule calendar event with user) and another potential attack vector (that account gets hacked/exposed) and another set of credentials to remember/store... just eww The suggested solution: Gmail should work just like connecting Google Calendar: allow multiple Gmail connections per user + per subaccount. This means that I consider part of this request to be a UX bug because I expected that when I connected my Gmail within Subaccount settings, that connection was scoped to that Subaccount. Ticket# 6488663 Related: https://ideas.gohighlevel.com/users-permissions/p/user-level-permissions-for-email-2-way-sync-access
0
·
Enhancement
Load More
→