Design principle
Workflows should be transparent and co-created. Anyone affected by a process should be able to see how it works.That is the module’s stated philosophy, and it is why the editor is visual and why instance state is inspectable rather than internal.
Anatomy
A workflow is a graph:
Instances are started with their subject — an employee, an application, an expense
report — and advance as steps complete. A failed step is recorded as failed rather than
silently retried into oblivion, so a stuck process is visible.
Editing
The editor is a node graph. You add steps, connect them, and configure each one. Because a workflow change reshapes every future instance, configuration isADMIN-level (pipeline:configure), while running instances and completing steps is
day-to-day work.
Changing a workflow does not rewrite instances already in flight. They finish on the graph they
started with — the same principle as versioned contract templates and reference-question catalogs.
What runs on it
Onboarding and offboarding
Task checklists with owners, offsets and reminders.
Absence approval
Manager approval resolved through the org graph.
Expense approval
Two-level approval with return-for-correction.
Recruitment pipeline
Stage effects — mails, tasks, document requests.
Events
Workflows both emit and consume events. A workflow can be started by an event —contract.signed starting onboarding — and
completing a step emits an event other modules can react to.
This is what keeps process wiring out of the modules themselves: the pre-boarding
orchestrator does not know the onboarding checklist exists, and vice versa.