Building a workflow
The workflow editor: stages and their inspector, transitions and conditions, the three tiers of validation, and how versions activate without affecting running cases.
Workflow definitions are authored in a full-screen editor rather than in configuration files. A definition version moves from draft to active to retired, and activating a new version does not affect cases already running on the previous one.
- Open the current version and start a draftthe live one is never editeda person
- Lay out the stages and the paths between thema person
- The canvas refuses edits that cannot workas you make them, not at the endautomatic
- Validate against the servera dry run — nothing is savedautomatic
- Activate, with a reasonnew cases start here; open cases stay where they area person
Stages
The canvas has a single node type, a stage. Variants are rendered as badges on it: start, terminal, waits on core, waits on borrower, effect count, and gated.
Selecting a stage opens an inspector with seven sections: the stage itself, what lets a case in, what lets it out, the facts it needs, the work it plans for the workforce, the effects it runs itself, and its gates.
Planned work — task type, the worker-facing label, the queue, and the condition under which it is created — is populated from a live server vocabulary rather than a fixed list, so a stage cannot plan work for a task type that does not exist. Effects come from a fixed set.
Node positions are not stored. Layout is computed from the shape of the flow, and auto-arrange discards drag overrides rather than tidying them, so the same definition renders identically for everyone.
Transitions and conditions
Every stage has exactly one otherwise path plus conditional branches, which are tried first. Dragging between two stages opens a dialog offering three interpretations: add a conditional path, make it the otherwise path, or splice a new stage into the middle of the existing path. Replacing the default happens in one step.
Conditions are built from a source, a field, an operator and a value, over seven server-supplied sources and twelve operators, and are rendered back as prose — is at least, is not recorded.
Validation
Each tier catches what the one before it cannot see
- 1The canvas, continuously"Stage needs exactly one otherwise-path (has 2)" · "The flow needs a terminal stage — it must end somewhere"
- 2The server, on demanda dry run that saves nothing: unknown task types, queues, facts or conditions — and the compliance rules a generic flow may not reach around
- 3Activation, once more and stricterstages nothing can reach, stages nothing leads out of, paths that dead-end, loops back to themselves
The validator never accepts a definition the evaluator could not run.
Versioning
What activating does
- Every new case of that type starts on this version
- The previous version retires
- Open cases stay pinned to the version they started on
What it cannot do
- Change a case already running
- Edit a live version in place
- Activate anything imported — imports arrive as drafts
Two people editing the same draft never overwrite each other: a save that arrives second is refused, and the editor offers to reload rather than discarding the newer work. A revision arriving from elsewhere does not overwrite unsaved work: the editor reports the conflict and offers to reload, and undo history survives a save. Work in progress is kept in browser storage and offered back after a lost tab. Every write requires a reason. A new case type starts from a server-written two-stage scaffold, and imports create drafts only.
Configured fields
Case types carry configured fields, authored in the admin screens. Nine field types — short and long text, integer, decimal, boolean, date, date-time, single and multiple choice — each with its own validation, defaults, and a requiredness of optional, required to create, or required to close.