One process. Eleven hand-offs.
Every hand-off between systems is a place where data is re-keyed, reconciled, or dropped. Press the switch.
Systems stay. The process layer changes.
Two steps, one definition. The panel is configured once and placed wherever it's needed — change it in one place and both stages change.
All three run concurrently. The parent step advances only when every lane clears — and any one of them can send it back.
Click either Panel Review — three reviewers open and run concurrently inside the parent step.
Rejected at Review? It returns to Submitted with the reason attached — and the loop is part of the process, not an exception someone handles by email.
See real ones — workflows running on the engine today
The diagram above is a teaching example. These are actual workflows in the platform, rendered live: grey is not yet traversed, blue is already traversed, green is where the item sits right now.
Nodes are statuses. The labels on the connectors are the named transitions that move an item between them — Submit, Passed, Correction, Reschedule, Re-apply. Nothing is compiled; the process is the configuration.
Two details worth noticing, because they are the parts that are hard to build: a single Reschedule Gate serves all three reviewers rather than each carrying its own logic, and candidates who don't proceed land in a Past Applicants Database with a Re-apply route back in. The process has a memory.
And processes are versioned — the change-management flow above is at v11.0. It has been revised eleven times without a release, a migration, or a developer.