What a successful RPA run can hide

That distinction matters when an application changes. A workflow may continue running by falling back to screen coordinates, matching an image or accepting input it could not verify. These are useful recovery mechanisms. They can also leave a process relying on assumptions that were not there when it was recorded.

We reviewed the warning messages in our desktop automation layer and found eight that deserve closer attention. They cover several different situations: a missing window, an element recovered through a fallback, uncertain keyboard focus, an unverified entry and an incomplete table extract. One records a refusal to choose between ambiguous targets.

These messages are more informative than a pass or fail count. They show where the runner had to depart from the recorded method, where it could not confirm the result, or where it reached the limit of what it could safely recover.

The important question is what happens to that information. If it stays in a log that nobody reviews until a run fails, the opportunity to investigate earlier is lost.

What the success rate leaves out

A success rate is useful for tracking availability and obvious failures. It is a poor measure of how closely a workflow still matches the application it was built for.

Consider two clicks. The first resolves a recorded selector and acts on the live element. The second cannot resolve the selector, so it clicks where the element used to be. Both may reach the right place. Both may allow the run to finish. But they do not provide the same assurance.

The second click now depends on the layout staying within whatever tolerance the fallback allows. A further change could expose that dependency.

This does not mean every fallback is a defect, or that every warning predicts a failure. It means a completed run and a verified business result are different things. Reporting that treats them as interchangeable leaves the process owner with an incomplete picture.

1. The target is missing, so the runner uses its old position

The simplest fallback is positional. The runner cannot find the recorded element, but it still has information about where that element was.

If the application window is available, it can place the action relative to the window bounds using the recorded offset. If the window itself cannot be found, it can use the original screen coordinates without a live window or element to anchor the action.

Both behaviours have their uses. An application may expose a poor accessibility tree while keeping a predictable layout. A coordinate-based action can be a deliberate and workable choice in that environment.

The concern is an unplanned change from element-based targeting to positional targeting. A workflow that used to identify a particular field is now relying on that field remaining in the same place. Moving a panel, changing display scaling or opening an extra toolbar may be enough to affect it.

The warning gives the owner something specific to review: not just whether the click worked this time, but whether the method it now relies on is still acceptable.

2. Recovery finds a likely target, rather than the recorded one

Other fallbacks use more context than a pair of coordinates.

An image template match compares the current screen with an image captured when the task was recorded. Geometric recovery uses the positions of neighbouring elements to recover a target that can no longer be found through its recorded selector.

These methods can keep useful work running through a minor interface change. They also need to be visible to whoever maintains the workflow. Otherwise a temporary workaround can become a permanent dependency without anyone deciding that it should.

One warning makes that maintenance request explicitly:

'{taskType}' target was recovered via orphaned-element geometric fallback rather than the recorded selector — the UI may have changed; consider re-recording this task.

The runner has recovered a target and explained why the recording may need attention. A dashboard showing only that the run completed would miss the second half of that result.

The practical response need not be to stop the process. It might be to review the changed screen, confirm the recovered target and update the recording. What matters is that someone receives the request.

3. Sometimes recovery should stop

Geometric recovery can find several plausible targets. If the recording contains no element index to distinguish them, the runner refuses to choose.

That is a useful limit. Acting on an arbitrary candidate would turn uncertainty into a potentially incorrect action.

This warning needs to be treated differently from a successful fallback. It records a recovery attempt that was declined; on its own, it does not establish the final outcome of the step. That depends on the surrounding execution path.

For the process owner, the immediate task is to remove the ambiguity, not to make the runner more willing to guess.

4. The runner typed, but could not confirm the entry

Data entry deserves particular attention because sending keystrokes is not the same as confirming a field’s value.

Two warnings describe this problem. In one case, the runner could not confirm keyboard focus on the target element, but continued with the action. In the other, it could not complete clipboard verification and accepted the input without verification.

The risks are different. Without confirmed focus, the input may have gone to another field or another part of the application. Without read-back verification, the intended value may have arrived correctly, but that check has not established that it did.

Neither warning proves that the data is wrong. Equally, a successful step status does not resolve the uncertainty. The relevant evidence is missing from that action.

For a process that updates financial or customer records, this should affect how the result is reviewed. Is there a later check against the saved record? Does the application return a confirmation? Is an exception raised if the value cannot be read back? The answers determine whether the uncertainty is contained or simply passed downstream.

This is a familiar control problem, rather than a peculiarity of automation. An action was attempted, but its completion was not verified by the expected check. If a later control supplies that assurance, retain the link to it. If nothing does, the run should not be presented as though the entry had been confirmed.

The warning is useful precisely because it tells you which assurance is absent.

5. The extract succeeded, but returned only part of the table

A table extraction can succeed technically while returning less data than the business process requires.

The runner limits the number of rows returned in a single request. When a grid exceeds that limit, it returns the permitted rows and records a warning:

Grid has {totalRows} rows; result truncated to the first {MaxRowsPerRequest}. Use GetTableRow + GetTableRowCount to iterate the full set.

The limit itself is not the problem. Bounded requests are a reasonable way to manage large results. The problem arises if the next step treats that response as the complete dataset.

A reconciliation might then compare only a subset of records. A report might omit later rows while still containing plausible totals. Whether another control catches the omission depends on how the workflow was designed.

The warning supplies both the reason and the alternative approach. Where completeness matters, the workflow should iterate through the full set and check the returned count against the expected count. A successful extraction status is not a substitute for that check.

What this means for controlled processes

For teams responsible for financial reporting, customer records or other controlled processes, the last two findings raise separate questions.

First, can you demonstrate that an update took effect? A record of an attempted action is useful, but it is not the same evidence as a confirmed saved value.

Second, can you demonstrate that an extract is complete? A valid response containing rows is not enough if the task requires every row.

Existing controls may already answer these questions. A downstream reconciliation, a saved-record check or an independent record count can provide assurance that the individual automation step could not. The point is to check that those controls exist and are connected to the result being reported.

Warnings help identify where that review is needed. They should inform exception handling and operational reporting, rather than remain available only to the person debugging the next failure.

Using the warning history during diagnosis

When a step does fail, its earlier warnings can help explain what changed. A missing selector looks different if the same step has recently relied on image matching or positional recovery.

Our current diagnosis process includes that history. It receives the failing step’s prior warnings, most recent first, alongside the error, the step description and neighbouring steps. That gives the diagnosis more context than the final error alone.

There is an important limit to this change: reading warning history after a failure is not the same as monitoring warnings before one. It improves diagnosis, but it does not by itself close the earlier reporting gap.

To address that gap, an operator still needs a way to review recurring fallbacks, identify unverified actions and route material warnings to the person responsible for the process. Those decisions depend on the consequences of getting the step wrong.

A proposed repair still needs a decision

The diagnosis produces a proposed repair. In the default manual mode, it does not apply that repair automatically.

Where automatic attempts are enabled, they are limited to element-not-found, timeout and resource-not-found errors. Network and permission failures are excluded from that set: changing a workflow is not a general remedy for an unavailable service or missing access.

Approval and execution are also separate. By default, approving a repair edits the workflow without rerunning the failed step. Rerunning requires a separate per-workflow opt-in because it acts on a real machine and may affect business records.

The approval records the authenticated user’s identity and the workflow content hash used for diagnosis. If the workflow has changed in the meantime, the repair is refused rather than applied against a version the reviewer did not assess.

These controls preserve the distinction between accepting a suggested change and authorising the operational action that follows it.

What to look at next

Start with a workflow that appears healthy. Review its recent warnings, especially repeated positional fallbacks, entries without verification and truncated extracts. For each, ask whether there is a later check that confirms the business result.

Some warnings will reflect an acceptable design choice. Others will point to a recording that needs updating or a completeness check that was never added.

That review is more useful than assuming every warning is urgent, and safer than assuming a successful run makes every warning irrelevant. The logs already contain information about how the work was done. The next step is to make sure that information reaches someone who can act on it.