Choose a robotic process automation task with clear inputs, a bounded action and a recognisable exception route. Define what the bot may read or change, who owns its access and what happens when a step fails. Use the exception worksheet below before automating a process that can create records or trigger work for another team.
Which task is a sensible automation candidate?
Start with a repeatable task whose operator can explain the normal route and the reasons for stopping. Ask them to show a typical item and an awkward one. Record the point at which they use judgement, consult another person or lack enough information. Keep that point explicit when deciding the proposed automation boundary.
Microsoft describes desktop flows as extending Power Automate robotic process automation. Documentation. Power Automate desktop flows can use prebuilt actions or recorded flows. Documentation. These descriptions establish ways of constructing automation, but the workflow brief should come first. A recording of successful clicks does not specify which records the process is allowed to affect or what should happen with an unusual input.
Microsoft describes desktop flows as suitable for rule-based workstation tasks. Documentation. Describe the rule in terms another operator can apply. For example, a proposed process might copy an approved reference into a draft record only when the source and destination match agreed identifiers. Let a person decide ambiguous matches. Avoid making the bot invent the missing business decision simply because the interface permits another click.
What should the automation identity be allowed to do?
Create an access inventory for the proposed task. List the application, the records required, the permitted operations and the person responsible for that access. Separate reading a source document from approving a transaction or sending a message. Ask the system owner which account and permissions are appropriate before implementation.
Microsoft lists UI elements, images and coordinates as ways to interact with a machine. Documentation. Use this to examine how the proposed automation identifies its target. Request a rehearsal in which an element moves or an unexpected dialog appears. Specify the stop condition when the intended target cannot be established. The design should not rely on an operator guessing what the bot clicked after the event.
Keep credentials outside the process specification and its demonstration material. The useful artefact is a reference to the approved access arrangement, not a copy of a password. Decide who can change that arrangement and who notices when an account or application policy changes.
An original task-and-exception worksheet
Use this practical checklist to define a candidate process before enabling operational writes. Fill it with the actual source, destination and handover roles. The entries are design prompts for a proposed automation, not results of an executed bot.
| Process boundary | What to specify | Exception to rehearse |
|---|---|---|
| Input admission | Approved source and required identifiers | Reference is absent or ambiguous |
| Destination selection | Account and record identity | Similar names point to different records |
| Permitted action | Draft, update or approval boundary | Action requires additional authority |
| Completion evidence | Record or status expected after the action | Confirmation does not arrive |
| Retry decision | Steps safe to repeat and state to inspect | Earlier write may already have succeeded |
| Human handover | Owner, reason and evidence reference | Exception remains unclaimed |
| Recovery | How the next safe action is established | Bot stops between related operations |
Add a task identifier to each proposed work item. Retain enough context for a person to determine what the bot attempted, while keeping unnecessary sensitive information out of routine logs. Agree the retention and access arrangements with the responsible organisation.
Write a human handover instruction for each stop reason. A useful exception includes the item reference, the uncertain step and what has already been established. A message saying failed gives the next operator too little information to resume safely. Define who receives the item and how the team recognises that it has been taken over.
How do errors change the continuation decision?
Microsoft distinguishes design-time configuration errors from execution-time exceptions. Documentation. Runtime exceptions occur during desktop-flow execution. Documentation. Keep setup problems separate from failures in a running process. A missing required configuration value needs correction before execution; an interruption after a write needs investigation of the destination state before another attempt.
Desktop-flow warnings do not prevent execution. Documentation. Review warnings in the acceptance conversation rather than treating an absence of a fatal error as the whole decision. Ask the implementer to show which observations remain unresolved and whether they could change the intended action sequence.
Desktop flows stop when an error occurs unless error handling changes that behaviour. Documentation. Specify the intended handling for each consequential failure. Sometimes stopping for a person is the correct outcome. Where continuation is proposed, identify what evidence makes it appropriate and which earlier results can still be trusted.
Power Automate supports common error handling for a block of actions. Documentation. When a block retry policy applies, the retry starts at the beginning of the block. Documentation. Review the block boundary carefully. If an early step creates a record and a later step fails, repeating the block needs an explicit decision about the record already created. The worksheet should ask how that state is checked before any retry is enabled.
Hypothetical example: a draft created before a timeout
Imagine a proposed bot reads an approved request, creates a draft in another application and then waits for confirmation. The confirmation step times out. In this hypothetical rehearsal, the key question is whether the draft exists, not whether clicking create again would be easy.
Use synthetic records in the demonstration. Pause after creation, inspect the destination through an agreed read route and retain the task identifier. Ask how the automation would distinguish a completed write from an action that never reached the application. Record the explanation and any part still requiring a person.
Then rehearse an ambiguous source reference. The proposed bot should route that item according to the agreed exception rule rather than choosing the first similar result. Ask the receiving operator to work from the exception record alone. Improve the handover until they can determine the next authorised action without reconstructing the entire run.
What evidence supports a decision to enable it?
Prepare a small acceptance bundle containing the task definition, access reference, normal-route observation and exception rehearsals. State which application version and environment were used. Assign an owner to maintain the rule when a form, record structure or business decision changes.
For a wider workflow brief, see web development. Keep the proposed RPA task distinct from the business automation selection guide, which covers choosing work across the organisation. Get started with the bounded task and its difficult exception if you want to discuss requirements with Spout.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.