Users, roles and permissions
Give each member exactly the access their job needs, with five roles enforced at the database.
Every member of your organisation holds one of five roles. Permissions are enforced by row level security at the database, not just hidden in the interface, so a role limit holds everywhere the data can be reached.
The capability matrix
| Capability | Viewer | Sales | Engineer | Admin | Owner |
|---|---|---|---|---|---|
| View everything in the organisation | Yes | Yes | Yes | Yes | Yes |
| Requests, create quotes, orders and customers | Yes | Yes | Yes | Yes | |
| Run configurators, register and process service items | Yes | Yes | Yes | Yes | |
| Edit catalogue, schemas, services, configurators and stock | Yes | Yes | Yes | ||
| Imports, connections, API keys and integrations | Yes | Yes | |||
| Pricing rules, special prices, organisation settings and users | Yes | Yes | |||
| Billing and plan | Yes |
Sales can run configurators and create service intake but cannot edit the definitions behind them. That split lets the commercial team price with the tools engineering builds, without changing how they calculate.
Invites
Admins invite by email with a role attached. Invites are expiring links that can be resent or revoked from the pending list. Pending invites count against your seat allowance until accepted or revoked.
Owner safeguards
- Only an owner can grant or change the owner role.
- The last owner cannot be demoted or removed, so an organisation is never left without one.
- Billing and organisation deletion are owner only.
Connections you approve for AI assistants over MCP are also capped by your own role, so a sales member cannot grant an assistant engineer powers. See the MCP connector page in Integrations.