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
Approvals exist, but they are improvised through a Gmail send-and-wait or a ClickUp task polled until approved, revision, rejection or timeout — the approver is whatever email address or ClickUp assignee you configure, with configurable poll interval, max attempts and reminder threshold standing in for real deadline and escalation handling. The form in the showcased process is a Google Form, and role routing is done with switch nodes reading a data table rather than platform roles or substitutes. Higher tiers add workflow history and Git version control, but we found no public information on running instances staying on their original version when a process changes, or on a task inbox for participants. 2 6 7 12