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 Integration Engineer
Forms, portals and the SLA machinery are real — due dates and per-phase late and expired alerts in minutes, hours or days, weekday-only counting, and alerts that trigger automation actions put this above a simple trigger chain. But we found no public information on parallel paths, on approval steps assigned to roles or groups with substitutes and escalation chains, or on versioning of a process definition for instances already in flight; the alerts page only says changed settings apply to new cards. 5 6 9