Approvals
CAB quorums, service-request approval steps, quorum rules, and the separation-of-duties floor under all of it.
Change approval — the CAB
Every change type carries a CAB approval policy with a platform quorum floor a tenant can raise but never lower:
| Change type | Minimum approvers (floor) |
|---|---|
| Standard (pre-approved, low-risk) | 1 |
| Normal (CAB review) | 2 |
| Emergency (expedited) | 1 |
By default the eligible approver roles are Change Approver (CAB) and Service Owner. Through workflow configuration you can raise min approvers, narrow the eligible roles, or point the policy at a specific group — the Regulated (DORA) preset does exactly this, raising Normal to 3 and Emergency to 2.
Approval mechanics worth knowing:
- Reject short-circuits. A single reject vote moves the change toward Rejected; approvals collected so far do not outvote it.
- The implementer cannot be the deciding voice. After the quorum count is met, the implementer's vote is excluded — if every approver is the implementer, the approval is not satisfied and the gap is surfaced explicitly.
- A group beats roles. If a policy names an approver group, group membership decides eligibility; otherwise the role list does. An empty role list means nobody is eligible — deliberately, so a misconfigured policy fails loudly rather than open.
Service-request approvals
Approval for service requests is configured per catalog item, not globally. A request model declares ordered approval steps, each with an approver role and a quorum (default 1). A model either requires approval (and must define steps) or doesn't (and must not) — there is no ambiguous middle state. Requests against a no-approval model skip straight to fulfillment.
Approvers see their pending votes in My work and in the approvals queue; the queue is role-scoped, so two approvers with different roles see different lists.
Quorum rules
A policy's quorum rule — any, majority, all, or first responder — describes how the required count relates to the eligible approver pool. The enforced floor is always min approvers; majority and all can raise the effective requirement further when more eligible approvers exist.
Separation of duties — beneath configuration
Whatever you configure, these hold, because they are enforced in the domain layer, not in settings:
- The requester of a change cannot approve or reject it.
- The implementer cannot be the sole effective approver.
- A service-request approver cannot approve their own request.
Dual-approval flows
Beyond records, four-eyes approval guards the platform's most sensitive operations: switching off a sticky regulatory feature flag, de-pseudonymizing a user's data, and granting sensitive role assignments (which expire after 14 days if not decided). Each is its own explicit request-and-approve surface with a full audit trail — see why regulatory toggles are sticky.