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 — No human steps at all: neither forms nor approval steps, only machine-to-machine automation.
3 — A visual builder with branching and a simple approval or form step.
5 — A visual designer with conditions and parallel paths, forms and approval steps assigned to roles or groups, and deadlines or reminders for open tasks.
8 — BPMN 2.0 modelling or an equivalent documented notation, versions of a process kept with running instances on their original version, 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
The visual drag-and-drop builder with multi-step scenarios and custom JavaScript or Python is documented, and the captured templates show real branching — the lead flow falls back from an email lookup to a phone lookup — plus an approval routed to the manager by email, Slack or Teams with an approve/decline link. That is a simple approval step, not governed participation: I found no public information on a forms designer, deadlines, escalation chains, substitutes or a task inbox. The pages also say nothing about versioning a process that is already running, so a business owner changing it without breaking live instances is not something I can see. 1 3 4 6