Roles and permissions
In Plainwater AI a role determines what someone may do. A role is a bundle of permissions, and every screen and every call asks for a specific permission. Roles are data: you can create custom roles without anything in the platform having to change.
Signing in
You sign in with your organisation account through Microsoft Entra ID. After sign-in the platform reads from its own database which roles you have. A user who can sign in but is unknown or inactive may do nothing.
The four fixed roles
| Role | Intended for | In short |
|---|---|---|
| Administrator | Platform management | All permissions, including users and roles |
| Consultant | Whoever does the work | Work items, conversations, sources and ground rules of their customers |
| Reviewer | Whoever checks and approves | Reading, assessing, approving or rejecting proposals |
| Viewer | Whoever only reads | Viewing work items and dashboards |
The fixed roles cannot be changed or deleted. The administrator always has exactly all the permissions the platform knows.
Custom roles
Alongside the fixed roles you create custom roles. A custom role is a selection from the existing permissions. You cannot invent a new permission. Examples:
- Dashboard maker: create dashboards and datasets, but not change sources or ground rules.
- Data owner: manage a customer's ground rules, but not run work items.
- Auditor: read everything, including transcripts, but change nothing.
Only an administrator creates and changes roles.
Roles per customer
A user has a global role and, in addition, a role per customer. A consultant can be a consultant for customer A and only a viewer for customer B. For a customer where you have no role, you do not exist. You get a 404, as if the customer does not exist.
Rules that always apply
- Permissions come from the database, again on every call, never from the request or the token.
- Nobody changes their own roles, an administrator included. There is therefore always at least one administrator left without a separate rule being needed.
- Nobody disables themselves.
- Every permission change is recorded in the platform audit.
An attempt to raise your own permissions immediately becomes a critical alert for the administrators.
Refusals and alerts
Every refused call becomes a data point, with the route pattern and without the full URL. A security monitor recognises patterns, such as someone probing many customers, night work with no history or a wave of deletions. It turns these into an alert under Admin → Alerts. Handling an alert is recorded too, and is final.
Handlers
Separately from roles you can set handlers on a work item: the people who should respond to it. A work item can have several handlers or none. "Waiting for me" counts the work items waiting for review or for a person where you are a handler, plus the work items without a handler.
Example
A consultancy has eight consultants, two reviewers and a director who only views dashboards. The administrator creates the role Dashboard reader with only the permission to view dashboards, and gives the director that role for all customers. A new consultant gets the consultant role for two customers. If he tries to open a third customer, he gets a 404. If he repeats that at several customers, an alert appears for the administrator.