Repair an automation when the business process still makes sense and you can trace its failures to specific, testable causes. Consider rebuilding when the workflow no longer matches the work, its dependencies have changed, or nobody can establish what happened when a run stopped. If the process no longer justifies its operating cost, retirement belongs in the decision too.
Start by examining one failed transaction. A useful assessment should explain what went wrong, what the automation already changed, and what a safe recovery would involve. That evidence gives you a firmer basis for a decision than the number of times someone has restarted the bot.
Find out what people mean by broken
An automation can stop for a valid reason. An invoice without a required purchase order needs a business decision; rerunning the same invoice won't supply the missing information. A temporary application outage calls for a different response.
UiPath makes this distinction in its queue behavior: application exceptions can trigger retries when automatic retry is enabled, while business exceptions do not receive automatic retries by default. The classification matters because it changes what the system does next. UiPath documentation
For your assessment, separate failures by cause and consequence. Record the affected business item, the step that stopped, and the work a person had to perform afterward. Include successful transactions in the review so you can see which conditions differ.
If all you have is a list of failed runs, first improve the evidence. A run marked successful also deserves scrutiny if employees still need to correct its output.
Match the remedy to the evidence
Use this table as a starting point for discussion. It proposes assessment criteria; it does not diagnose a workflow without inspecting it.
| What the evidence shows | First option to investigate | What would change the decision |
|---|---|---|
| One screen change broke a step, while the process and other steps still work | Repair that interaction and test the affected paths | Frequent interface changes make ongoing maintenance impractical, or a supported integration offers a better route |
| Missing or invalid input repeatedly stops work | Add input checks and a clear human exception path | The business rules themselves are inconsistent or no owner can resolve exceptions |
| A temporary service failure interrupts an otherwise valid transaction | Review timeout handling and bounded retries | A retry could repeat an action whose result is unknown |
| Nobody can tell which records changed before the failure | Establish transaction evidence and a recovery procedure before resuming work | The current design cannot support reliable reconciliation without substantial changes |
| The process, target application, or business need has changed materially | Re-scope the workflow and compare replacement with retirement | A small, testable change still meets the revised need at a defensible cost |
A repair should have a boundary you can describe. For example, “detect the new page state, locate the field reliably, and verify the saved record” gives a reviewer something concrete to test. “Make the bot more reliable” leaves too much undefined.
Check recovery before adding retries
Retries can help with temporary failures. Microsoft's Power Automate guidance describes retry settings for intermittent service or network problems, including intervals and a maximum retry count. Those settings need to match the failure you are handling. Microsoft error-handling guidance
Consider a hypothetical order-entry workflow. It submits an order, but the confirmation screen never appears. The automation reports a timeout. The order may already exist in the destination system.
Repeating the submission could create another order. Before choosing a recovery action, establish whether the first submission succeeded using the destination's supported lookup or reconciliation process. Where available, use a destination-enforced unique business reference or idempotency mechanism. A separate lookup followed by a write can still race with another process, so it is not an automatic duplicate guarantee.
Microsoft also advises Power Automate developers to account for duplicate inputs when designing flows. Its examples include checking for existing documents and using key constraints to prevent duplicate records. Microsoft trigger troubleshooting
For an operations owner, the practical question is whether the team can recover a transaction without guessing what happened. If that answer is unclear, include recovery design in the work estimate.
Compare the work left to do
The original build cost cannot tell you which option is better now. Compare the future work and risk under each option over the same planning period.
For a repair, include diagnosis, implementation, regression testing, and expected support. For replacement, include those costs plus migration, any parallel operation, staff changes, and retirement of the old workflow. Check current software terms and charges before including them.
Also record the work that remains with people: exceptions, output checks, approvals, and incident recovery. An automation that completes more runs may still leave the team with substantial manual effort.
A useful estimate makes its uncertain inputs visible. If nobody has measured incident time, collect a representative sample rather than presenting a precise annual saving. Hours released for other work are capacity; cash savings require a separate explanation of which expenditure would actually fall.
Bring this worksheet to the assessment
Choose a failed business item and work through these questions with the process owner and technical maintainer. Use redacted examples and approved access methods.
| Question | Evidence to collect |
|---|---|
| What was supposed to happen? | Expected business outcome and acceptance criteria |
| What happened before the failure? | Relevant run history and confirmation of changes in each destination |
| Why did it stop? | Specific error, input condition, or dependency failure; mark unknowns |
| What does safe recovery require? | Reconciliation steps, duplicate controls, and an accountable decision owner |
| What would prove the remedy works? | Representative normal and exception cases, including an interrupted transaction |
The assessment should leave you with a bounded recommendation, the evidence supporting it, and a way to check the result. Sometimes that will be a small repair. In other cases, it will reveal that the surrounding process needs attention before another build can succeed.
If your team keeps restarting an automation without a clear explanation of what failed, talk with AB Consulting about the process. We can help assess the problem and scope the repair or implementation work it needs.