Review an automation after a process change by tracing the changed requirement through its inputs, rules and destinations, then checking the affected behavior against the newly approved process. Do not stop at confirming that the workflow still runs. It may be executing the old rule correctly.
Start with one specific change and a small impact record. Identify what should now happen differently, what must remain unchanged and which cases need investigation before the changed workflow is allowed to handle them.
Write down the approved difference
Describe the old requirement and its replacement without immediately editing the automation. A changed field name, a different receiving team and a revised business rule are different kinds of change. Record who confirmed the new requirement, when it applies and which workflow version you are inspecting.
In a fictional community arts club, an internal event request previously led to a printed handout preparation task for every event. The club now lets organizers select either paper or digital materials. The intended new rule is to create the print task only for a confirmed paper request.
That is not merely a new form label. The workflow needs to read the selected format and apply a different condition. A run could finish without an error while still creating unwanted print tasks for digital events. This example is invented; it describes no actual club, automation or measured saving.
Follow the change to the people receiving the result
Trace the relevant field from its source to the final output. Check how it is named, which values are allowed, whether it is required and what a missing or unfamiliar value should mean. Ask which calculations, conditions, documents and destinations use it. Inspect the actual configuration with the authorized maintainer rather than relying on the form's visible wording alone.
For the arts-club example, the review could use this original working record:
| Affected part | Question to settle |
|---|---|
| Request form | Does the submitted record contain a confirmed paper or digital choice? |
| Decision rule | Does the print-task condition use that actual value rather than an old default? |
| Preparation list | Can the receiving coordinator distinguish print work from events needing no print task? |
| Older requests | Which approved rule applies when the request predates the new choice? |
| Exception route | Who resolves a missing, invalid or conflicting choice before work is assigned? |
Talk to the person using the result. A technically valid task may still leave them unable to identify the event or understand why it reached their list. Check the receiving view, not only the step that creates it. Do not widen access or copy private records into a general review document to make that inspection easier.
Choose tests from the difference, not from a generic checklist
Write expected results before running the changed version. Include a case that should change, a case that should continue working and a case where the new information is unavailable. Each test should answer a particular question raised by the change.
For the fictional club, a confirmed digital request should create no print-preparation task. A confirmed paper request should still reach the correct preparation list. A request without a usable format should follow the club's agreed clarification route, not silently become paper or digital.
Keep existing requests separate from newly submitted ones. Do not let the person implementing the change guess whether old work should be converted, retained under the previous rule or reviewed individually. That is a process decision to confirm before testing historical cases.
The separate guide to testing missing or duplicate automation inputs covers broader exception behavior. Here, the reason for selecting each case is the specific change and its dependencies.
Keep simulated results separate from integration evidence
Use an authorized test setup with fictional records and controlled destinations. Record which steps actually ran. In Power Automate, Microsoft's testing guidance distinguishes checking a flow from running it and explains that a static result substitutes for an action rather than executing it. Passing a simulated branch therefore does not establish that a receiving system was updated correctly.
For the print-task example, simulated input can help examine the paper-versus-digital condition. A separate permitted integration test is needed to inspect what arrives in the preparation list. If that route cannot be tested safely, leave it unverified with a named owner rather than describing the whole workflow as checked.
Do not replay an old live request simply because it is convenient test data. The same Microsoft guidance warns that resubmission can duplicate records or emails. Establish the existing outcome and an authorized safe testing route before any repeat action.
Identify the version that was actually checked
Record the configuration version, test input, expected result, observed result and evidence location together. A successful test of yesterday's configuration does not settle a change made afterward. Retain failed findings as well as the corrected result, so another reviewer can understand what changed.
Use version controls your actual system supports. Microsoft's cloud-flow drafts and versioning guidance applies to solution-aware flows in the new designer, not every flow. It distinguishes saving a draft from publishing runtime changes; restoring a previous version produces a new draft.
Do not treat a saved older configuration as a universal undo button. It does not by itself remove tasks already created, reconcile queued requests or reverse work a person has started. Have the responsible owner define how affected work will be handled if the changed workflow must be stopped. Keep that recovery question distinct from whether the new rule passed its tests.
Close the review with a bounded decision
State which change and cases the evidence covers. Record unresolved dependencies, who can authorize adoption and what observation is needed after a permitted release. A result such as paper and digital branches checked with fictional requests; receiving-list test still outstanding is more useful than an unsupported declaration that everything works.
Ongoing responsibility belongs with an accountable automation owner. This review gives that person a decision record: the approved difference, affected dependencies, tested version and remaining gaps.
For a short planning continuation, Preparing SOPs for Automation covers validation, integrations, test scenarios and review cycles. It helps organize the procedure, but does not supply a configured regression suite or rollback system. Explore related Automation resources in AI & Technology.
