Workflow Design Principles
The seven-part structure every automated workflow needs, and the specification to write before you build anything.
Most workflows fail on the parts nobody designed: what happens when the data is wrong, when the system is down, or when the same thing arrives twice.
The happy path is the easy part. It's also about twenty percent of the work.
This is the structure we use for every workflow we build, and the specification we write before touching a tool.
Request Your Free Systems Audit · See the frameworks
The seven-part structure
Trigger → Conditions → Actions → Notifications → Record Update → Follow-up → Reporting
Every workflow has these seven parts. Workflows that break are usually missing one of the last four.
1. Trigger
What starts it, and where the data comes from.
A trigger should be a specific event, not a schedule standing in for one. "Every hour, check for new orders" is a workaround for not having an order event. It works, but it introduces delay and silent failure when the check itself stops running.
2. Conditions
Validation, filtering, and deduplication, before anything is written anywhere.
Deduplication deserves its own thought. Decide what makes two records the same — email, then phone, then name plus date — and what happens on a match. Most duplicate problems are designed in at this step.
3. Actions
What happens, in order, with the dependencies explicit.
Order matters more than it seems. If step three fails, steps one and two have already run. Design so that a partial run leaves a recoverable state, not a half-created record nobody knows about.
4. Notifications
Who gets told, and when.
Separate internal notifications from customer-facing ones. Internal ones can be noisy; customer-facing ones need approval, correct timing, and a consent check where the law requires it.
A workflow that notifies on every run trains people to ignore it. Notify on exceptions, summarise the rest.
5. Record update
Which fields change, which stage or status, which tags, who owns it afterwards.
Write this as a mapping table before building:
| Source field | Destination | Transformation | If missing |
|---|
The last column is the one that gets skipped and the one that causes the most incidents.
6. Follow-up
What happens next, and when, if nothing else does.
Every workflow that waits for a human response needs a timeout. Without one, records sit in a stage indefinitely and nobody notices, because nothing failed — it just never finished.
7. Reporting
Where you see that it ran, and where you see that it didn't.
The second is harder and more important. A workflow that errors visibly gets fixed. A workflow that silently stops running gets discovered when someone asks why they haven't heard anything in two weeks.
The eighth thing: a stop condition
What makes this workflow stop applying to a given record?
Without one, follow-up sequences continue after the customer has replied, reminders fire after the task is done, and nurture emails reach people who already bought. This is the most common cause of a workflow producing an embarrassing output rather than a broken one.
Design for the unhappy path
Before building, write down what happens in each of these cases:
A required field is missing. Stop cleanly, notify, create nothing partial. Never substitute a default for a value you needed.
The same input arrives twice. Deduplication rule applies, no duplicate record, no duplicate message.
An external system is unavailable. Retry with a defined interval and limit, then notify a human. Don't retry forever and don't fail silently.
The run is interrupted halfway. Either the whole thing can be re-run safely, or the partial state is detectable. Decide which, and say so.
Volume spikes. Ten executions in a minute shouldn't hit a rate limit that drops nine of them without a trace.
Designing these is roughly half the work. It's also the difference between a demo and something you can leave running.
The specification, before you build
Write this document first. Every time.
WORKFLOW: [name]
Purpose: [one sentence]
TRIGGER
Event:
Data source:
CONDITIONS
Validation:
Deduplication:
Filters:
ACTIONS
1.
2.
NOTIFICATIONS
Internal:
Customer-facing: [approval required: yes/no]
RECORD UPDATE
Field mapping: [table]
Stage / status:
Owner:
FOLLOW-UP
Timing:
Condition:
ERRORS
Retry rule:
Escalation:
Logging:
Manual override:
STOP CONDITION
REPORTING
Success visible at:
Failure visible at:
WHAT THIS DOES NOT DO
-
That last section prevents more misunderstandings than any other part of the document.
Acceptance tests
A workflow isn't finished when it works. It's finished when it has survived these:
| Test | Expected result |
|---|---|
| Normal case | Completes, all fields populated correctly |
| Required field missing | Stops cleanly, notifies, no partial record |
| Same input twice | No duplicate created |
| External system down | Retries per rule, then escalates, no data lost |
| Ten consecutive runs | All complete, no limits hit |
| Stop condition met | Workflow correctly stops applying |
Run them, write down the results, keep the record. When something breaks in four months, this is what tells you whether it ever worked.
Before production
Build in a test environment. However small the workflow. "It's just a notification" is how production incidents start.
Get approval in writing for anything that contacts customers or changes financial records.
Write the rollback. How it gets switched off, what needs correcting manually if it ran wrong, who is allowed to stop it.
Supervise the first real run. Watch one genuine case go through end to end before walking away.
When not to build
| Situation | What to do instead |
|---|---|
| The process isn't documented | Document it first |
| It changes every few weeks | Wait for it to stabilise |
| It runs twice a month | Leave it manual, write the procedure |
| Every execution needs judgement | Support the decision, don't replace it |
| Failure wouldn't be detectable | Build the detection first |
"We could automate this" and "we should" are different questions. The second one includes the cost of maintaining it forever.
A workflow is only as good as its error handling. The happy path is the demo. Everything else is the product.
Have a process that might be ready to automate?
A free systems audit tells you whether it is — and what the build would actually involve.