The five parts of a workflow that actually runs
- Trigger. A form submitted, an email arriving, a record changing status, a time of day.
- Payload. The facts the workflow needs — customer, amount, document, requester — already structured.
- Steps. Who or what acts, in what order, and what “done” looks like for each step.
- Exceptions. What happens when a step fails, a person is away, or the data is incomplete.
- Record. Who did what, when, and why. Without this, nobody will trust the system with anything that matters.
Most demos show parts one and three. Production is parts four and five.
Happy path versus the work
Take a purchase request. Happy path: under the limit, manager approves, purchase order is raised. Real life: the manager is on leave, the amount is just over the limit, the supplier is new, the attachment is a photo of a handwritten quote. If those cases fall on the floor, staff invent a side channel — WhatsApp, a spreadsheet — and your automation becomes optional.
Design the exception path first. It feels backwards and it is how workflows survive contact with a real office.
Where this sits next to ERP and AI
If the workflow lives entirely inside one system of record, configure that system. Do not build a second one beside it. If the work crosses two or three systems, you need integration — often a small .NET service — not another login. If the trigger is an unstructured document, you need extraction first; that is the generative or RAG part, sitting in front of an otherwise ordinary workflow.
Start from business process automation if you are still deciding whether this is the right kind of project.