Should you automate or redesign this process?

Describe what the automation should produce: create a request, update a status or notify an owner. “Connect our systems” remains too broad. Identify the starting event, the authoritative information and the outcome someone will be able to verify.

Then ask whether the task needs to exist in its current form. If two teams maintain separate lists because neither knows about the other, synchronising those lists is only one option. A shared source or clearer ownership also deserves consideration before building a connection.

Simplify when information is requested repeatedly, an approval no longer has a clear purpose or the same check happens several times. Clarify the rule before expressing it in software.

Automate when the necessary data is available and the result can be checked. Define one action, then examine the technical conditions for implementation. Prototype when a dependency remains uncertain, such as the reliability of an input or a system’s ability to receive an update. A focused trial can answer that question without committing the entire workflow.

An incomplete request and an unavailable service need different responses. For each situation, decide whether the flow stops, waits, alerts someone or hands over to a person. Also define how to recognise an item already processed, so a restart does not create two records.

For Power Automate desktop flows, Microsoft documents design-time and runtime errors alongside configurable recovery mechanisms. Those mechanisms do not choose the business rule. The organisation still needs to decide how each situation should be handled.

Handle errors in desktop flows

A fictional company wants to transfer requests from its form to its sales system. Contact details follow a stable format, but assignment depends on a geographic territory that teams interpret differently.

The project is split. The team first clarifies its assignment rule and separately examines record creation using a unique identifier. A request without a valid territory would go to a designated person. This scenario illustrates a test scope; it is not a delivered integration or a guaranteed saving. The trial should include both a normal submission and a request that reaches the exception path.

For each question, record “confirmed”, “needs checking” or “undefined”, together with the available evidence. Several positive answers do not remove the need to examine a critical unresolved point.

• Are the intended outcome and its owner identified?
• Has an authoritative source been chosen for each item of exchanged data?
• Have system permissions and exchange mechanisms been checked?
• Do duplicates, refusals and missing information each have a defined response?
• Can a person resume a case without repeating actions that already succeeded?
• Does someone own monitoring, changes and ongoing costs?

Prepare fictional data for the normal path and known exceptions. Verify the result in the destination system. A success message in the starting tool does not fully explain what happened. Agree on how to suspend the trial and handle requests left waiting.

Compare work removed with work added: checks, corrections, monitoring and maintenance. Record volume assumptions and the limits of the trial. A useful decision may be to automate one transfer while keeping human approval elsewhere. To scope feasibility, bring together the systems involved, the business rule and examples of exceptions. Keep the decision record understandable to the person who will maintain the workflow later.