Workflow configuration

Settings → Workflows (permission settings.workflow.edit) configures the four record-type workflows: Change, Incident, Problem, and Service request. The change workflow additionally carries its three CAB approval policies.

The layering model

What a user actually experiences is resolved from three layers, most specific first:

1. Your tenant's overrides — per-transition label, visibility, and required-field changes; per-policy quorum changes.
2. The active preset — a platform-curated starting point you pick per workflow.
3. The platform superset — the real state machine, in code, from which both layers may only subtract or decorate.

A fresh tenant with no overrides behaves exactly like the platform default. Removing your configuration restores it precisely — there is no drift to unwind.

Presets

Three preset families ship, and onboarding pre-selects one from your signup profile:

• SMB Lite — small team, low ceremony. Friendlier labels ("Take ownership", "Mark done"), nothing tightened.
• Standard ITIL — canonical ITIL vocabulary ("Submit RFC", "Begin implementation"), platform CAB quorums unchanged. The default fallback.
• Regulated (DORA) — for DORA / NIS-2 / BAIT estates. Tightens the change workflow: submitting requires a change justification, approval requires a regulatory impact assessment, the normal-change CAB quorum rises from 2 to 3 and the emergency quorum from 1 to 2, and approver eligibility narrows to the CAB role. Closing an incident requires a linked problem.

Presets only ever decorate or tighten — switching presets can never take your tenant below the platform floor.

What you can edit

Per transition: the label, whether it is hidden, and additional required fields. Per approval policy: minimum approvers, the quorum rule, and the eligible approver roles or group.

The editor flow is: pick a workflow → pick a preset → author overrides → Preview → Save (or Reset to platform default). Preview is non-destructive and reports exactly the violations a save would reject, so you never discover a problem after committing.

The doctrine: tighten, never loosen

Every save is validated against the customization doctrine. You can:

• Relabel any non-compliance transition.
• Hide transitions your process doesn't use.
• Add required fields to any transition — including compliance-gated ones.
• Raise an approval quorum above the platform floor, or narrow who may approve.

You cannot:

• Invent a transition or change where it goes — the state machines are code.
• Hide or relabel a compliance-gated transition, or drop a platform-required field.
• Lower a quorum below the platform floor (Standard changes: 1, Normal: 2, Emergency: 1), or add approver roles the platform doesn't allow.
• Touch separation of duties. Requester ≠ approver and implementer ≠ sole approver are enforced in the domain layer and are not reachable from configuration at all.

A violating save is rejected with a structured list of exactly which rules it broke. Every accepted save writes one audit event.

The state machines being configured

The four state machines themselves — states, transitions, permission requirements, and required fields — are documented per record type in the Service desk section: incidents, problems, changes, and service requests.