# 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. :::warning Self-elevation is an alarm 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. :::tip Read on - [Ground rules per customer](https://plainwater.ai/en/wiki/beheer/spelregels) - [Security guarantees](https://plainwater.ai/en/wiki/veiligheid/garanties) :::