Field and step access
Sometimes a role is not granular enough: everyone can edit a risk, but only Legal should change the regulatory-exposure field. That rule lives in the layout, not the role builder.
Why in the layout? Because the same field is editable in one register and read-only in another. The restriction belongs to the placement, not to the field and not to the role.
The rule that keeps this sane
A layout rule can only take away. If the grant table does not let you open the record, no layout rule gives you a field. If you do not hold Edit risks, marking a field editable does not make you an editor. Layout rules filter on top of access — they are never a second way in.
Three modes per field
| Mode | Effect | Use it |
|---|---|---|
| Follows the record | No rule. Whoever can edit the record can edit the field. | The default, and right for about 90% of fields. |
| Read-only for others | Everyone still sees the value; only the named audience can change it. | The useful one. Write control, not secrecy — reports and exports still reconcile. |
| Hidden from others | The field is invisible outside the audience. | Rarely. Exports differ per viewer and two people comparing the same register will disagree. |
Who the audience can be
Best first:
- A role and above
- Anyone with a specific permission
- A relationship to the record — owner, raiser, assignee, named approver
- A group
- An organisation unit and below
- One named person — allowed, flagged as an exception, and surfaced in access reviews
There is no field-level delete
Clearing a value is editing it, so write control already covers it. Deleting the field itself is a settings action that reaches every layout at once. A per-field delete switch would look reassuring and control nothing, so it does not exist.
Step rules
Most “only X can do this” requests are really about progressing the record rather than about a field. Each stage carries:
- Who may complete it — the audience allowed to move the record on.
- Enforce segregation of duties — whoever raised or is assigned the risk cannot complete this step, even if their role allows it.
- Freeze on completion — fields become read-only for everybody once the step is done, including risk managers. Reopening is a separate, logged action.
Freeze on completion is what makes an approval mean something. Without it, an approved assessment can be quietly edited afterwards and the approval records nothing.
Validation on save
Field permissions fail silently — a required field nobody can write throws no error when you save the layout, it throws one six weeks later as “I can’t submit this risk and I don’t know why”. So four checks run on every save:
- Required, and nobody matches the write audience → blocks save
- Required and hidden → blocks save
- A step nobody can complete → blocks save; only one person can → warning
- Pinned to a named person, plus any hidden field → warning
Reviewing what you built
Two views worth checking before publishing: a fields × roles matrix showing read/write/none for each combination — the artefact an auditor asks for — and preview as somebody, which renders the real form as that person sees it.