Roles and Permissions
The role system controls what features and data users can access within an account.
Default Roles
Owner
Full access to all system features, including:
- Managing user passwords
- Access to all users’ private mailboxes
- Managing WebChat widgets
- All administrative permissions
Administrator
Administrative permissions:
- Managing users and their roles
- Account and domain configuration
- Managing mailboxes and folders
- Viewing and undoing activities
- Access to billing and reports
- Managing roles and groups
- Approving leave requests
- Moderating knowledge base comments
User
Standard access to:
- Profile and dashboard
- All enabled modules (tasks, mail, CRM, forms, knowledge base, etc.)
- Viewing activities
- Commenting on tasks
Guest
Limited access:
- Profile only
- Requires administrator approval (moderation)
Custom Roles
You can create custom roles with any combination of permissions. A custom role lets you precisely define which modules and features a user can access.
Permissions are divided into:
- Module-level — access to modules (Organize, Mail, CRM, Forms, Knowledge Base, etc.)
- Operational — creating, editing, deleting within a module
- Functional — access to specific features (activities, users, domains, billing, API tokens, webhooks)
When creating a role, you cannot assign permissions higher than your own role.
Role Inheritance (Basing on Another Role)
A custom role can be based on another role — a built-in or another custom role. It then automatically inherits all its permissions, and the administrator only adds additional ones.
Example: you create a “Salesperson” role based on the User role and add the Insight permission. The Salesperson then has everything the User has plus Insight — without manually checking every checkbox.
Inheritance works in a cascade — a role can be based on another custom role, which in turn is based on a built-in one.
Custom Privileges
In addition to system permissions (module access, user management, etc.), a role can have custom privileges — arbitrary names defined by the administrator.
Custom privileges are used to control access to things that have no equivalent in system permissions, such as:
- Access to a specific Noe application
- Ability to export reports
- A permission specific to a company process
Enter them as a comma- or space-separated list of names.
Best practice: use dots in names (e.g., app.crm, report.export, custom.invoices). This makes it immediately clear that it’s a custom privilege rather than a system one, and there won’t be name collisions if a system permission with the same name appears in the future.
If a custom privilege name matches a system permission name, the system one always takes priority — custom privileges only work for names that don’t exist in the system.