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.
A leave request, written as a workflow
Trigger: staff submit a form. Payload: who, dates, balance already looked up. Step one: if days remaining cover it and the dates do not clash with a shutdown, notify the manager. Step two: manager approves or refuses within two working days. Step three: on approve, write the absence into the attendance system and mail the staff member. Exceptions: manager away — escalate to their manager after 48 hours; balance too low — reject with the number; form incomplete — do not start. Record: every transition with who and when.
That is a workflow. It is not AI. It should not be sold as AI. If the request arrives as a free-text email instead of a form, then you have an extraction problem in front of the same path.
Where people hide the real process
WhatsApp groups named after the workflow. A spreadsheet “just for this month”. A printed checklist on one desk. If you automate the official path and leave those in place, you have built a museum exhibit. Part of the project is agreeing that the official path is the only path, which is a management job the software cannot do for you.
Building it without a second system of record
Prefer configuration in the ERP or HR package you already pay for. If that package cannot route or cannot log, a dedicated service that updates the package is still better than a new database of leave. Duplicate records are how you spend the next year reconciling.
Triggers that survive a real office
A form submit is clean. A status change in the system of record is clean. “When someone emails the group” is only clean if you control the mailbox and you have a rule for the mail that is not work. A time-of-day trigger — “every weekday at 9, send the overdue list” — is underrated. It does not need AI. It needs a query and a person who will act on the list.
Do not trigger on “when it feels busy”. That is not a trigger. That is a feeling. Software cannot subscribe to feelings.
Audit trails people will actually use
Who moved the work, when, from what status to what status, and which rule fired. If you cannot answer “why was this approved on Tuesday?” in thirty seconds, finance will not trust the path. Screenshots in a WhatsApp group are not an audit trail. A row in a table is.
We build this as ordinary ASP.NET logging against the same database as the work, not a separate “automation platform” you cannot query. If the ERP you already pay for can log transitions, use that. A second log is how you spend Friday reconciling whether the workflow and the ERP agree.
What we refuse to call a workflow
A Zapier recipe that posts to Slack when an email arrives, with no owner and no record in the system of record. A spreadsheet with a macro only one person can run. A chatbot that “sorts tickets” by guessing, then writes to the customer. Those can be useful toys. They are not a workflow you can show an auditor or a new hire on day three.
A workflow is boring on purpose. Trigger, payload, steps, exceptions, record. If you cannot point to each part, you have a script. Scripts die when the person who wrote them leaves. Workflows survive because the path is the product, not the hero.
Purchase request, the version that survives leave
Trigger: form submitted. Payload: requester, amount, supplier, attachment, cost centre already chosen from a list. Under the limit: manager is notified; two working days or it escalates. Over the limit: second approver. New supplier: stop and open a task for accounts, do not invent a vendor code. Attachment missing: do not start. Record: every transition. The WhatsApp group named “PO urgent” is closed when this path is live, or the workflow is optional and will die.
That is longer to write than a demo. It is the project. If you cannot get agreement on the limit and the escalation, you do not have a workflow problem. You have a policy problem. Software should not pretend to settle it.
Build it in the package you already pay for if that package can route and log. If it cannot, a small .NET service that updates the package is still better than a second database of purchase requests. Duplicate records are how Friday disappears. The wider “should we automate at all” test remains when to automate a process.
Start from business process automation if you are still deciding whether this is the right kind of project. If you are not sure the process is ready, read when to automate first.
Closing the side channel on go-live week
Pick a Thursday. The official path is the only path that creates a PO. The WhatsApp group is read-only or deleted. Someone senior says that out loud. If you cannot say it, you do not have a workflow — you have a demo next to the real office. Software cannot retire a group chat. A manager can. Put that sentence in the statement of work as a client obligation, or the build will be “done” and unused. A go-live that leaves the group alive is a training problem you have already scheduled for next year.