Custom Roles & Access Review
Defining additive custom roles beyond the built-in ones, redacting PII in traces by permission, and reviewing who has access to what.
Most teams are well served by the built-in environment roles — Read, Write, Run, Debug, and Admin — described under Environments. Custom roles exist for the cases those five do not cover cleanly: a support role that can see why a rule fired but not the customer data it fired on, or a narrow role you want to hand out by name across many environments.
Custom roles and access reviews are part of the Enterprise plan. On other plans the screen explains that your organization uses the built-in Read, Write, Run, Debug, and Admin roles today, and nothing on this page applies.
Any member of the organization can open this page and see what each custom role grants, which is deliberate: people should be able to check what a role they hold actually means. Only an organization admin sees the editing controls and the access review table. Everyone else sees a read-only list of the roles and their permissions.
Custom roles
An organization admin builds the role list on this screen. Add role appends a new row, and each role carries three things:
- Name — up to 50 characters. This is how the role is referred to everywhere else, so pick something people will recognize on sight, such as
Support Triage. - Description — up to 255 characters, explaining who the role is for. This is what a non-admin reads when they come here to check their own access, so write it for them.
- Permissions — chosen from a dropdown; a role can hold any combination.
Roles can be removed from the list, and Save custom roles writes the whole set at once. An organization can define up to 25 custom roles; once you reach the cap the Add role button is disabled and says so.
Assigning a custom role grants capability on top of what a person already has. It never takes anything away. A role that omits Write does not stop someone who already holds the built-in Write role from writing — to take access away, change the built-in roles on the environment’s user list instead.
This page defines the roles; it does not assign them. Roles are matched by name and assigned to individual people on the environment editor screen, alongside their built-in roles. Renaming a role here therefore matters — the name is the link between the definition and the people holding it.
Permissions
| Permission | What it grants |
|---|---|
| Read | View rule sets, logs, and run history. |
| Write | Create and modify rule sets, conditions, action sets, schedules, and variables. |
| Run | Execute rule sets. |
| Debug | See debug-level log detail. |
| Admin | Full control of the environment, including its users. |
| View PII values | See real context values in a trace instead of redacted placeholders. |
PII redaction
Redaction of personal data is not a switch somewhere else in the product; it is the View PII values permission on this page. By default, trace and log data shows redacted placeholders wherever a subject’s own values would appear. Only someone whose role includes View PII values sees the real values in their place.
Grant everything the job needs except View PII values. An operator with that role can still see which rules fired, in what order, and why — the whole explanation of the decision — while the subject’s own values stay masked. That is usually enough to answer “why did this happen?” without exposing anyone’s personal data, and it is the pattern the screen calls out directly.
Access review
Below the roles, organization admins get an Access Review table: a point-in-time roster of every person’s access to every environment in the organization, in one place rather than one environment at a time. Each row shows:
| Column | Shows |
|---|---|
| Person | The member’s name and email address. |
| Environment | The environment the access applies to. |
| Roles | The built-in roles they hold there. |
| Custom roles | Any custom roles assigned to them there. |
| Effective permissions | Everything the two sets resolve to together. |
The table is generated fresh every time an admin loads the page. It is not stored, scheduled, or emailed — what you see is the access that exists right now. Saving a change to your roles refreshes it automatically, so you can confirm the effect of an edit without reloading. If nobody has been granted access yet, the section says so rather than showing an empty table.
Implicit access
Some grants are marked with an implicit badge. That means the person has access to the environment because they are an organization admin, not because someone added them to that environment’s user list.
Implicit access does not come from the environment’s user list, so taking the person off that list changes nothing — they keep the access as long as they are an organization admin. To actually revoke it, change their role in the organization. Treat every implicit row as a reason to ask whether that person still needs to be an admin.
Exporting the review
An admin can review the roster on screen and export it as CSV or JSON. CSV suits a spreadsheet you circulate for sign-off; JSON suits feeding the roster into another system. Because the table is generated on demand and never stored, the export is how you keep a dated record that the roster was reviewed — which is exactly what an auditor asking for evidence of periodic access review wants to see.
Related
- Audit Log — changes to roles, and grants of access, are recorded there with who made them and when.
- Access & Security Policy — organization-wide rules about how people authenticate and how long their sessions last, which apply regardless of the roles they hold.
- Organizations — organization-level Owner, Admin, and Member roles, which are separate from the per-environment roles on this page.