Process design, forms & approvals
How this is scored
Modelling the process people take part in: a visual designer or BPMN, forms, approval steps with roles and substitutes, deadlines and escalation, and versioning of a process that is already running — judged on whether a business owner can change a process without breaking the instances in flight.
0 — Linear trigger-action chains only; no human steps, no forms and no statement on approvals or roles.
3 — A visual builder with branching and a simple approval step, but approvers are named individuals rather than roles, there are no deadlines or escalation, and changing a process has no versioning.
5 — A visual designer with conditions and parallel paths, built-in forms, approval steps assigned to roles or groups, deadlines with reminders, and versions of a process kept with the running instances on their original version.
8 — BPMN 2.0 modelling or an equivalent documented notation, substitutes and escalation chains, multi-stage approvals with four-eyes rules, forms in German with validation and file upload, a task inbox for participants, and a test or simulation mode before publishing.
10 — The process is a governed asset: version history with diff and rollback, migration of running instances to a new version documented, process analytics on cycle time and bottlenecks per step, and the design documented well enough that a business team can maintain it without the vendor.
The Skeptic
The documentation shows a real forms engine with validation, file upload and responsive layouts, task lists, deadlines with escalation settings, debug mode, and a clean separation between applying edits to one running instance and saving a new version of the model. We found no public information on approvers modelled as roles with substitutes or four-eyes rules, on a stated notation such as BPMN 2.0, or on diff and rollback for process versions, so this stops short of the governed-asset level. 5 6 10