Choose a process with a defined purpose
A repeated task is a useful place to look for automation, but repetition alone is not enough. Define the problem first: slow handovers, duplicate capture, missed follow-ups or too much time spent checking status. Decide what improvement would count as success before choosing a platform.
Microsoft's automation guidance prioritises clear, procedural tasks that are likely to remain useful long enough to justify the investment. A process can still contain human decisions. For a hypothetical purchase request, automation might record the request, notify an approver and track the response while the approver decides whether the purchase should proceed.
Map what happens in ordinary and unusual cases
Trace one request from its trigger to completion. Identify the information it needs, the person responsible at each stage, the systems involved and the evidence that a stage is finished. Include the people who do the work: written procedures may omit informal checks or workarounds.
Microsoft's process management guidance recommends mapping the current process and investigating delays and unnecessary steps before designing an improvement. For the purchase example, include missing supplier details, an absent approver, a rejected request and a changed amount. Decide which cases can follow a rule and which should return to a person. Resolve conflicting approval rules before implementing them.
Check the inputs and measure the effort
Review whether required information arrives consistently and can be matched to the right record. If every request uses a different description for the same supplier, a structured form or reference list may be the first useful improvement. Request only information needed for the process and define who should be able to see it.
Estimate volume, handling time and rework using a representative sample. As an illustration, 40 requests taking six minutes each represent four hours of handling. That is a starting estimate, not a promised saving. Allow for retained human work, exceptions, implementation, licensing, support and changes. A useful business case makes these assumptions visible.
Decide how failures will be handled
Describe what happens if a connection fails, an action times out or a required record cannot be found. Microsoft's Power Automate guidance covers alternative paths after failures, retries for temporary problems, and error notifications. These mechanisms still need a business decision about who responds and what they should do.
In the purchase example, a failed notification should not silently leave a request waiting forever. Decide how the owner finds it, whether another notification is safe, and how to avoid creating a duplicate request during recovery. Keep diagnostic records useful without copying unnecessary personal information into alerts. Define a workable manual route for interruptions.
Pilot with an owner and a review date
Start with a manageable scope and test ordinary cases, exceptions and recovery. Compare results with the agreed baseline: processing time, incomplete requests, manual corrections or missed handovers. Ask the people using the workflow whether the new process is understandable and whether it has moved work elsewhere.
Name the business owner and the person responsible for maintenance, access changes and failures. Record how future changes will be requested and checked. A process is a stronger candidate when its purpose, rules, inputs and ownership are specified in enough detail to test. Where these remain uncertain, a process review or a smaller automated step can be the practical next move.