One process. Eleven hand-offs.
Every time work passes from one system to the next, somebody retypes it, somebody checks two versions against each other, or it quietly gets lost. 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. There is no code underneath — the picture is the thing that runs.
Two details worth noticing, because they are the parts that are hard to build: one rescheduling step handles all three reviewers, instead of each reviewer needing their own, 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.