Multi-step workflow engine built from scratch

Challenge

The client had several internal processes with the same shape: a sequence of steps, each with an owner, a deadline and a completion criterion. Each of those processes had been solved with its own dedicated screen and rules scattered inside it. None of them had a tracked deadline. And changing the order of a step meant touching code.

The request that came in was for one new process. Except several just like it already existed.

Solution

Instead of delivering yet another dedicated screen, I built a generic workflow engine inside the ERP, split into four pieces by responsibility.

Step definition. The flow’s definition became data: sequence, owner, deadline, advancement condition and what fires on completion. Changing the flow means changing configuration.

Activation and advancement engine. It is the only piece that knows how to change the state of a flow instance. It validates the advancement condition, records who advanced it and when, and activates the next step. No screen writes state directly.

Side effects per step. Completing a step can trigger a business action. In the first process rolled out, one of the steps creates the product in the ERP’s registry using the data already accumulated along the flow, which put an end to the retyping that used to happen at the end of the process.

SLA job. It runs asynchronously, looks for overdue steps and notifies. It is what gives the configured deadline any practical effect.

There is also an operational dashboard that shows where each instance is stuck, for how long, and with whom.

Outcome

The first process went into production on top of the engine. The second one was configuration only, with no new development. The most visible management gain is the overdue alert: information that used to surface only when someone complained now arrives on its own.

What this case shows

I saw that the one-off request was an instance of a wider class, and solved the class. The design separates who defines the flow, who changes its state and who displays it on screen. Deadlines here are part of the process, not a report someone pulls afterwards.