[Intum Help](https://intum.com/help.md) / [Account](https://intum.com/help/account.md)

# [Roles](https://intum.com/help/account/roles.md)

## 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.