A form submission becomes a task
Fictional example: request R-204 names an existing account. The workflow finds its owner and creates a follow-up task. It does not decide whether to offer a discount.
A workflow can begin with an event, a schedule or a person starting it. Microsoft documents all three starting points; starting a flow manually does not make every later step manual.
| Step | Automated handling | Stop or review |
|---|---|---|
| Receive R-204 | Capture the account reference and request | Missing reference goes to the intake reviewer |
| Find the owner | Look up the owner on the matched account | No match or several matches requires review |
| Create the task | Assign the task with the request reference | A failed write remains unresolved |
| Approve a discount | Route the request to the authorised reviewer | Wait for their decision before applying it |
What makes work automatable
Check the trigger, inputs and expected result.
Condition 1
The trigger is definable as a rule
Something specific and consistent causes this step to happen. A record reaching a certain stage. A date passing. A form being submitted. If the condition for action requires someone to read a situation and decide, 'this feels like the right moment', the trigger is not automatable yet. The judgment lives in the trigger, not just the action.
Condition 2
The output is consistent enough to template
Every instance of this step produces something structurally the same. A message in the same format. A record updated the same way. A notification sent to the same channel. If every instance requires a different response because the context is different, the output requires human judgment. If the variation is just in the data filled into a template, the output can be automated.
Condition 3
The data to drive it actually exists in a system
Automation cannot synthesise context that lives in someone's memory or inbox. If the trigger and the template both depend on information that is not captured in a system, a commitment made in a meeting, a relationship nuance that only one person knows, the automation will either misfire or require the same human involvement to set up correctly each time. The data problem comes before the automation problem.
Where I keep human review
Keep a reviewer for consequential decisions.
Reading a situation and deciding what is appropriate. Maintaining trust in a relationship where the person matters, not just the outcome. Handling exceptions that do not fit any predefined rule. Making a decision where the wrong answer has consequences. Providing accountability for an outcome. Software can collect evidence and route a review request without making the decision itself. I keep consequential judgements with a person who has the context and responsibility to review them.
The useful distinction
A successful run does not prove the right task reached the right person.
Check the assigned owner, task content and any required approval against the original request. Missing information should leave a visible review task with a named owner. This is my operating recommendation, not a measured claim about the causes of automation failures.
