Roles & Permissions (RBAC)
concorbit uses role-based access control (RBAC) to manage what each team member can see and do. The Roles & Permissions page, called the Role Master: lets you create custom roles, assign granular permissions, and enforce MFA policies per role.
URL: /settings/roles
Required permission: roles.view (to view), roles.manage (to edit)
Accessing Roles & Permissions
Go to Settings from the sidebar.
Click the Roles & Permissions card (described as "Manage team access control").
Understanding Roles
A role is a named set of permissions. When you assign a role to a user, that user gains all the permissions included in the role. Every user has exactly one role.
Default (System) Roles
concorbit ships with four system roles that cannot be deleted. They are marked with a "System" badge:
| Role | Description |
|---|---|
| Administrator | Full access to all features and settings. Can manage users, roles, billing, and workspace configuration. The workspace creator is assigned this role and flagged as the workspace owner. |
| Manager | Access to operational features (CRM, Email, Billing, Vault, Docs) with create/edit/delete rights. Limited settings access. |
| Staff | Day-to-day operational access. Can view, create, and edit records but may have restricted delete and export permissions. |
| Customer | Portal-only access (dashboard and own profile). Used for client portal logins rather than staff. |
System roles can have their permissions edited but cannot be renamed or deleted.
Custom Roles
You can create unlimited custom roles tailored to your organisation's needs (e.g., "Sales Team", "Finance", "External Contractor").
Creating a Custom Role
Click the New Role button in the top-right corner.
In the modal:
Enter a Role Name (e.g., "Sales Team").
Select permissions from the categorised checklist (see Permission Categories below).
Use the All / None buttons at the top to quickly select or clear all permissions.
Use the per-module Select all / Clear buttons to toggle all permissions within a module.
Click Create Role.
Editing a Role
Find the role in the roles list.
Click Edit permissions on the right side of the role card.
The permission matrix expands below the role, showing every permission organised by module.
Use the checkboxes to toggle individual permissions on or off.
Click Save Changes when done, or Cancel to discard.
Bulk Selection
The expanded permission matrix includes several bulk selection helpers:
Global "Select all": enables every permission (excluding vault tier, which is handled separately).
Global "Clear all": removes every permission.
Per-module "Select all / Clear": toggles all permissions within a single module.
Counter display: shows "X of Y selected" both globally and per module, so you can see at a glance how much access the role has.
Deleting a Custom Role
Click Delete on the role card.
Confirm in the dialog.
You cannot delete system roles. You also cannot delete a role that still has users assigned to it, reassign those users to a different role first.
Permission Categories
Permissions are organised by module. Each module has a set of granular permissions that control specific actions. Here is the full breakdown:
Core Permissions
| Permission | What it controls |
|---|---|
| dashboard.view | Access to the main dashboard |
| profile.edit | Ability to edit own profile settings |
| settings.tenant | Access to workspace-level settings (Brand, SMTP, Workspace, Support Access) |
CRM Permissions
| Permission | What it controls |
|---|---|
| crm.view | View contacts, companies, deals, tasks, and appointments |
| crm.create | Create new CRM records |
| crm.edit | Edit existing CRM records |
| crm.delete | Delete CRM records (moves to trash) |
| crm.export | Export CRM data to CSV |
Email Permissions
| Permission | What it controls |
|---|---|
| email.view | View email campaigns, templates, and logs |
| email.create | Create new campaigns and templates |
| email.send | Send campaigns and individual emails |
| email.delete | Delete campaigns, templates, and email records |
Billing Permissions
| Permission | What it controls |
|---|---|
| billing.view | View invoices, credit notes, products, and subscriptions |
| billing.create | Create new invoices, credit notes, and products |
| billing.edit | Edit existing billing records |
| billing.delete | Delete billing records |
| billing.send | Send invoices and payment reminders to clients |
| billing.payment | Record manual payments and manage payment methods |
Vault Permissions
| Permission | What it controls |
|---|---|
| vault.view | View vault folders and secrets (subject to tier restrictions) |
| vault.create | Create new vault folders and secrets |
| vault.edit | Edit existing vault entries |
| vault.delete | Delete vault entries |
| vault.reveal | Reveal the plaintext value of encrypted secrets |
Vault Access Tiers
Vault folders are organised into three visibility tiers. These are mutually exclusive: selecting a higher tier automatically includes all lower tiers:
| Tier | Slug | What it unlocks |
|---|---|---|
| Staff | vault.tier.staff | Access to folders marked as Staff-level |
| Management | vault.tier.management | Access to Staff + Management folders |
| Director | vault.tier.director | Access to all folders (Staff + Management + Director) |
In the Role Master, vault tiers appear as radio-style buttons (not checkboxes) because only one tier can be active at a time. Selecting "Director" automatically grants Staff and Management access.
Per-user overrides: In the Users page, administrators can override the vault tier for individual users without changing their role. This is useful when a specific team member needs elevated vault access.
Docs Permissions
| Permission | What it controls |
|---|---|
| docs.view | View documentation pages |
| docs.create | Create new docs pages |
| docs.edit | Edit existing docs |
| docs.delete | Delete docs pages |
| docs.publish | Publish docs to the public or portal |
Portal Permissions
| Permission | What it controls |
|---|---|
| portal.manage | Configure portal settings and appearance |
| portal.invite | Send portal invitations to contacts |
Files and Media
| Permission | What it controls |
|---|---|
| files.download | Download uploaded files |
| files.upload | Upload new files |
| files.delete | Delete files |
| media.manage | Full access to the media library |
Administrative Permissions
| Permission | What it controls |
|---|---|
| audit.view | View the audit log |
| webhooks.manage | Create, edit, and delete webhooks |
| api.tokens | Create and manage API tokens |
| roles.view | View roles and their permissions |
| roles.manage | Create, edit, and delete roles; manage users |
| partner.clients | Access to agency sub-tenant management (Agency tier only) |
MFA Enforcement
Each role can have an MFA (multi-factor authentication) enforcement policy. This forces users with the role to set up two-factor authentication.
Configuring MFA Enforcement
Edit a role's permissions.
Scroll to the MFA enforcement section at the bottom of the permission matrix.
Check Require MFA for this role.
Configure:
Grace period (days): How many days after joining the user has to set up MFA before being locked out. Set to 0 to enforce immediately. Maximum 90 days. Default is 14 days.
Allowed MFA methods: Which methods the user can choose from:
Authenticator app (TOTP): standard time-based one-time passwords via apps like Google Authenticator, Authy, or 1Password.
Passkey (FIDO2): hardware security keys or biometric authenticators (fingerprint, face recognition).
At least one method must be selected. You can allow both, giving the user a choice.
What Happens When MFA is Required
Users who have not yet set up MFA see a prompt after login directing them to the MFA setup page.
During the grace period, users can dismiss the prompt and continue working.
After the grace period expires, users are redirected to MFA setup on every login attempt and cannot access the workspace until MFA is configured.
Roles with MFA required show a "MFA required" badge in the roles list for quick visibility.
Assigning Roles to Users
Roles are assigned to users from the Users page:
During invitation: Select a role when inviting a new user.
After joining: Expand the user's row in the Users table and change the role from the dropdown.
Each user has exactly one role. Changing a user's role takes effect immediately, they gain the new role's permissions and lose the old one's.
Permission Inheritance
Permissions are purely additive within a role. There is no concept of "deny" permissions. If a permission is checked, the user has that ability. If it is unchecked, they do not.
Vault tiers are the only hierarchical permission, selecting a higher tier automatically includes lower tiers.
Best Practices
Principle of least privilege: Start with minimal permissions and add more as needed, rather than starting with full access and removing.
Use custom roles for teams: Create a "Sales" role with CRM and Email permissions, a "Finance" role with Billing permissions, etc.
Enforce MFA for sensitive roles: Any role with access to Vault (especially Director tier), Billing, or Settings should require MFA.
Review permissions periodically: Use the audit log to spot users who may need more or fewer permissions based on their actual usage.
Related Documentation
User Management, inviting users, assigning roles, managing user status.
Security & Authentication. MFA setup details for end users.
Audit Log, tracking actions performed under each role.