On this page
Start with a task whose inputs, rules, and expected output you can explain to another person. Frequent repetition helps, but frequency alone is not enough. A process that depends on unspoken judgement may become harder to manage when that judgement is hidden inside an automation.
Choose the smallest useful outcome first: prepare a record, route a request, or remind an owner. Leave consequential decisions with a named person until the rules and checks are clear.
Decision at a glance
Choose a starting level of automation
| Task characteristics | Suitable starting point | Required control |
|---|---|---|
| Stable inputs and clear, repeatable rules | Automate a bounded step | Validation and a visible result |
| Clear preparation, judgement at the end | Prepare automatically; require approval | Named reviewer and rejected path |
| Frequent exceptions or changing rules | Standardise the process first | Written rules and exception examples |
| Hard-to-reverse external action | Keep final execution manual initially | Review, confirmation, and recovery plan |
Scroll horizontally to see the full comparison.
Compare the whole task, including rework
Observe a normal working week. For each candidate, record frequency, handling time, exceptions, and what happens after an error. Compare the work removed with the review and maintenance introduced. A task done occasionally may be easier to keep manual; a frequent task can still be unsuitable if every instance needs a different decision.
- Can you identify the event that starts the task?
- Are the required inputs available and consistent?
- Can you describe success and failure without guessing?
- Who owns exceptions and changes to the rules?
Write the exception path before connecting tools
Specify missing fields, duplicate events, unavailable services, and requests that do not fit the rule. Decide whether each should stop, wait, retry, or enter a review queue. Microsoft’s Power Automate guidance describes failure paths, retries for temporary errors, and error logging. These are design requirements to assess, even when you choose another platform.
Keep approval where the consequence warrants it
Hypothetical example, not a client project: an enquiry form creates a draft customer record and suggests an owner. A person reviews ambiguous entries before any customer-facing message is sent. Microsoft’s approval workflow documentation shows that review can be an explicit step. Decide who approves, what they see, and what happens if they reject or never respond. “Sent for approval” must not be treated as “approved”.
Test failure as deliberately as success
Test normal input, missing information, a repeated event, an unavailable connection, and an approval timeout. Require evidence of the final result in the destination system. If a retry could send a message or create a record twice, define and test how duplicates are prevented. Use test data and a review stage before enabling external actions. Write down how to pause the workflow and resume unfinished work.
Make operating the workflow part of the scope
Someone must receive actionable failure notices, review waiting items, maintain connections, and approve rule changes. Keep a record linking the input, action, and outcome so the owner can investigate a problem. Define a manual fallback and decide how long it is acceptable for work to wait. A workflow without an operating owner is not ready to run unattended.
Start with one workflow and explicit acceptance checks
Prepare a process map, representative test inputs, exception rules, connected systems, and an owner. Request a scope covering setup, approvals, logs, failure handling, and handover. Chronicle quotes scoped automation projects in USD; identify subscriptions and maintenance separately. If the rules are still disputed, document and simplify the manual process first. You can defer automation until the repeated work is stable enough to test.
Before you commit
Your decision checklist
- Start with a stable, bounded step.
- Specify duplicates, failures, and unanswered approvals.
- Verify the destination result, not just the trigger.
- Name an owner and keep a manual fallback.
Sources and further reading
The next step
Workflow automation
If this is the right direction for your business, start with a clear scope, testing plan, and handover.