Exception roles decide who may approve exceptions, per kind of record.
Each entry is a simple pairing:
| Field | Notes |
|---|---|
| Entity type | Which kind of record the permission covers — quotations today. |
| Role | Which role may decide on exceptions for it. |
Anyone holding a listed role can approve or reject exceptions of that entity type. Approving and rejecting also carry the roles used to make the decision, so the record shows the authority the decision was made under, not just the person.
Why this is separate from ordinary permissions
System roles say what someone may do — create a quotation, read an invoice. Exception roles say who may overrule a control. They are deliberately kept apart, because the person who raises quotations should not usually be the person who approves the ones that exceed a credit limit.
If the same role appears on both sides, the control does nothing. Someone who can create a quotation and approve its own credit exception has an unlimited credit authority in practice, whatever the limit field says.
Setting it up
- Decide who genuinely holds the authority. For credit exceptions this is normally finance or a commercial manager, not operations.
- Assign the role, not the person. People change jobs; the authority stays with the position.
- Keep the list short. Approval authority spread across many roles is approval authority that nobody exercises carefully.
- Check the separation. For each entity type, confirm the approving role is not the role that raises the request.
Reviewing it
Review exception roles whenever roles are restructured, and whenever the exceptions history shows decisions being made by someone you did not expect. The history names the decision-maker — see Working the exceptions queue.
Related: Building roles for the system-wide permission model.
Last updated 9 September 2026