D
Daniel Fundi Ndaya
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.
  1. 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.