Give business users a tool for building their own workflows and the first question from anyone responsible for the platform is the same: what stops them building something broken?
It is a fair question, and the usual answers are bad ones. Training does not scale and decays. Review boards reintroduce the bottleneck self-service was supposed to remove — now with a queue and no tooling. Trusting people is not a control.
The answer that works is a publish gate: a flow cannot become runnable until it passes a defined set of checks. Not a warning, not a linting suggestion. A gate.
Draft and published are different things
The gate only makes sense if the two states are genuinely separate.
A draft is a work in progress. It can be incoherent. It can have a step with no configuration, an edge going nowhere, a decision with no branches. That is what drafting is, and a tool that refuses to let you save an incomplete thought is a tool people fight.
A published version is an immutable snapshot: graph, task bindings and configuration frozen together at the moment of publication. Runs execute snapshots and only snapshots. Editing the draft afterwards has no effect on anything already running.
This separation is what makes the gate cheap. You are not validating continuously and nagging; you are validating once, at a moment the user has explicitly chosen, when they have declared they think it is finished.
What the gate should check
Broadly three categories.
Structural. Exactly one start. No unreachable nodes. No dead ends that are not an explicit end. Every parallel split eventually joined. These are graph properties, cheap to compute, and their violation always indicates a mistake.
Contractual. Every node bound to a task type that exists in the registry, and every node’s configuration satisfying that task type’s schema. This is where most real errors live — the approval step with no approver, the integration step pointing at an endpoint that was never filled in.
Semantic. The checks that need domain knowledge. Every loop must contain a decision, otherwise a run entering it can never leave. Every decision needs exactly one default branch, otherwise a case matching no condition has nowhere to go. Every variable read by a step must be written by some earlier step.
That last category is where a gate earns its reputation. A business user drawing a rejected-goes-back-for-resubmission loop is doing something completely reasonable and has not thought about termination. The gate thinks about it for them.
Errors and warnings are different
Some findings are unambiguous: an unbound task cannot run. Others are judgement: a step whose output nothing consumes is usually a mistake, but occasionally deliberate.
Treating both as blocking teaches users that validation is an obstacle to be worked around. Treating both as advisory means the blocking ones get ignored too.
So: errors block, warnings require acknowledgement — and the acknowledgement is recorded on the published version. Not a dismissed dialog; a durable note saying this person accepted this warning at this time. Six months later, when the unconsumed output turns out to have mattered, the record exists.
Why this is a project management tool
The gate looks like an engineering feature. Its effects land squarely on delivery.
It moves defects to the cheapest moment. A missing approver caught at publish costs thirty seconds. Caught in UAT it costs a defect report, a triage, a fix and a retest. Caught in production it costs a case handled wrongly.
It replaces review meetings with a checklist that runs. Everything mechanically checkable stops consuming human review time, which frees the review for the thing humans are actually needed for: whether this is the right process.
It makes “done” objective. On workflow projects, done is usually contested, because it rests on impressions of completeness. A gate makes at least part of it binary. It either publishes or it does not.
It converts training into feedback. Users learn the constraints of the system by hitting them, with a specific message, at the moment they are relevant. A validation message that names the node and offers to select it on the canvas teaches more reliably than any document.
The failure mode to avoid
The way to ruin a publish gate is to make its messages unactionable.
“Validation failed: invalid flow configuration” is worse than no gate at all, because now the user is blocked and uninformed, and their next move is to raise a ticket — which is precisely the outcome the whole system exists to prevent.
Every message should name the specific node, state what is wrong in the user’s vocabulary rather than the schema’s, and take them to it. “Manager approval has no assignee” with a click that selects the node beats a schema path every time.
Get that right and the gate stops being a barrier people resent. It becomes the thing that tells them they are finished.
Writing the rules down
A gate is only as good as the specific checks in it, and the semantic ones are worth enumerating because they are the ones that catch real mistakes. A workable starting set:
- Exactly one start. Zero means nothing can begin; more than one is almost always a copy-paste artefact.
- Every node reachable from the start. Unreachable nodes are either an error or a leftover, and both should be surfaced.
- Every path terminates at an explicit end. A dangling edge is a case that stops with no record of finishing.
- Every split is joined — or the flow explicitly declares that a branch ends independently.
- Every cycle contains a decision. Without a guarded exit, a case entering the loop never leaves.
- Every decision has exactly one default. Zero means a case matching nothing is stranded; more than one is ambiguous.
- Every node is bound to a task type that exists in the registry.
- Every configuration satisfies its schema.
- Every variable read is written earlier on every path that reaches the reader — the check that catches the subtle bug where a value exists on the happy path and not on the exception path.
- Every human task has an assignee or team. Otherwise the case arrives in nobody’s queue.
That last one is worth calling out because it is invisible in testing — the developer testing the flow is usually an administrator who can see everything.
Versioning and what happens to work in flight
The gate creates published versions, which immediately raises the question everyone forgets until the first change: what happens to cases already running when a new version publishes?
There are three defensible answers, and the wrong move is not choosing.
Let them finish on the old version. The default, and correct for most business processes. Cases are internally consistent, the audit trail is unambiguous, and no case changes rules mid-flight. The cost is that a fix does not reach cases already running.
Migrate them. Sometimes necessary — a regulatory change that must apply immediately. It is genuinely hard: a case sitting at a node that no longer exists needs an explicit mapping, and every migration is bespoke. Treat it as an exceptional operation with its own approval, not a routine capability.
Terminate and restart. Occasionally right for short-lived processes with no human work completed. Rarely right otherwise, because it discards work someone did.
Whatever you choose, record it on the version. “This version applies to cases started after 14 March” is the sort of sentence an auditor will want, and reconstructing it later from timestamps is miserable.
The metric that tells you the gate is working
Track the ratio of publish attempts to successful publishes, and the distribution of which checks fail.
A healthy system shows most publishes succeeding first time, with a steady tail of caught errors. Two patterns signal problems.
If almost nothing fails validation, the gate is probably too weak — real flows have real mistakes, and a gate that never catches anything is decoration.
If one check dominates the failures, that is not a user problem. It is a design problem: either the builder makes that mistake easy to make, or the rule is not discoverable until publish time. Both are fixed upstream — by preventing the mistake in the interface, or by surfacing the constraint while the user is making the relevant edit rather than at the end.
EFTEDRA builds workflow automation on IBM Business Automation Workflow and Claude — assistant tasks and coach views that install into the processes you already run. See what we build, or try the live demo.