Access Control

Access control decides what each teammate can view or manage.

Use access control when a teammate joins, changes responsibility, needs a temporary permission, or should no longer see a sensitive module. Access is a combination of workspace modules, role permissions, direct user permissions, workspace membership, and plan availability.

Access Control Areas

The access control page is organized into four areas:

• Roles: create custom roles and review system roles.
• Members: assign each workspace member to a role and manage direct permissions.
• Permissions: review the permission matrix by role and create custom permission keys when the workspace needs them.
• Audit: review recent changes to roles, members, and permissions.

Review all four areas when investigating access. A role change alone may not explain access if the member also has direct permissions, the module is disabled, or the plan does not include the feature.

Create a Role

1. Open Settings > Access Control.
2. Open the Roles tab.
3. Select Create role.
4. Enter a clear role name, such as Sales Manager or Project Coordinator.
5. Create the role.
6. Open the Permissions tab and turn on only the permissions that role needs.
7. Assign the role to one test member before using it broadly.

System roles are protected. Custom roles can be deleted when they are no longer used, but check the member count first so you do not leave teammates with the wrong access pattern.

Build new roles from the lowest practical access. Add permissions after testing the actual workflow instead of copying a broad admin role.

Review the Permission Matrix

Use the Permissions tab to compare roles against every permission group. Permissions are grouped by module or feature area. Turn permissions on for a role only when the role should be able to perform that action across the workspace.

For sensitive roles, review billing, domains, API keys, payment gateways, app credentials, and permission-management permissions separately. Those permissions can affect the whole organization, not just one record.

When a module is newly enabled, review its permission group before inviting more users. New modules often introduce finance, HRM, workflow, or settings access that should not be inherited casually.

Direct Permissions

Direct permissions are granted to a specific member on top of their role. Use them for narrow exceptions, such as a finance user who needs one extra reporting permission.

Avoid using direct permissions as a substitute for a clean role design. If many people need the same exception, create or update a role instead.

Permission Checks

When a user cannot access a page, check these in order:

1. The module is enabled for the workspace.
2. The user's role includes the required permission.
3. The user belongs to the correct workspace.
4. The feature is included in the current plan.

Owner-Only Work

Keep sensitive actions limited to owners or trusted admins, including billing, domains, API keys, payment gateways, app credentials, and broad permission changes.

Review owner/admin membership after team departures, finance process changes, and integration setup. Old admin access is one of the easiest ways for sensitive settings to drift.

Change Access Safely

1. Confirm the business reason for the change.
2. Prefer role changes for permanent responsibility changes.
3. Prefer direct permissions only for narrow exceptions.
4. Ask the teammate to refresh after the change.
5. Open the audit tab and confirm the change was recorded.

If a page appears or disappears unexpectedly, compare the member role, direct permissions, module status, and audit entries before changing more settings.

Related Docs

• Settings
• Assign Member Roles
• Manage Direct Permissions
• Review Access Audit
• Billing