Where RPA stalls on legacy apps is a short, nameable list

The trap in most RPA postmortems is treating every stall as one problem to harden against. It is not. The seven failure points below fall into different families, and they need different handling. A bot that cannot tell them apart either retries forever or dies on a transient.

Why legacy apps are where RPA goes to stall

A web app hands a bot a stable DOM: ids, classes, a real document model the bot can query. A legacy Windows desktop app hands it none of that. No API. Often no stable control ids. Frequently a window that, as far as the bot can tell, is just pixels. SAP GUI, Oracle EBS, mainframe terminal emulators, Jack Henry teller screens, Epic charting windows: every one of them predates the idea that a program other than a human would need to read it.

So a selector-based RPA platform invents a handle. It records an XPath, an automation id, a window title, an image template, a screen coordinate. Each of those is a guess about the screen's current shape, and each one is fragile in a different way. The bot is not bound to your workflow. It is bound to a snapshot of the UI taken on the day someone recorded it.

That is the whole story behind "where RPA stalls." The stall points are not exotic. They are the predictable ways a snapshot stops matching reality. Here is each one, why a selector or pixel bot breaks there, and what an agent that reads the operating system's accessibility tree does instead.

The seven places legacy RPA stalls

Sorted roughly by how often each one shows up in a stalled overnight queue.

A stall is a classification problem

Look at the seven failure points again. Most of them are recoverable if the runtime knows what kind of stall it hit. A coordinate drift needs a re-resolve. A connection blip needs a retry. A modal dialog needs a branch. Only the last one, a genuine workflow exception, needs a human. Traditional RPA collapses all seven into one outcome, "the bot stalled," and pages an engineer for every one of them.

Mediar's workflow executor does not. Before it decides what to do with a failure, it classifies it. The function that does this lives in crates/executor/src/config/retry.rs and it is called classify_error(). It buckets every failure into one of three categories by matching the error text against two pattern lists.

This is the part no general guide on RPA and legacy systems mentions, and it is the part that matters. "The bot stalled" is not an outcome. It is an unclassified event. A runtime that can name the category of a stall can recover from six of the seven failure points above without a human ever seeing them.

Every step declares what to do when it stalls

Classification answers "is this worth retrying." The second half is "what should this specific step do." In a Mediar workflow, each step carries its own error strategy. The enum is small and it is explicit.

// crates/executor/src/models/workflow.rs
pub enum ErrorStrategy {
    Stop,      // halt the run, log the step
    Continue,  // record it, move to next step
    Retry,     // re-run this step (retry_count)
    Fallback,  // jump to fallback_id branch
}

A read step from a slow SAP screen might be Retry with a retry count. A step that hits an optional confirmation dialog might be Fallback, jumping to a branch that dismisses the dialog and rejoins. A step that posts a financial transaction is Stop: if it fails, the run halts cleanly rather than guessing. And because the executor supports partial re-execution, a fixed run resumes from the step that stalled instead of replaying the whole workflow from the top.

The difference from a selector-based bot is that none of this is glue code an RPA developer hand-wrote per workflow. It is how the runtime behaves by default, the same way for SAP GUI, a Jack Henry teller window, an Epic chart, or a mainframe terminal.

The one stall you should not automate away

Failure point seven, a genuine workflow exception, is the honest limit. If a claim references a policy number that does not exist, no amount of retrying, re-resolving, or branching fixes it. The right behavior is to stop, log the step and the reason, and surface it to a person. A runtime that quietly retries a real exception is worse than one that stalls visibly, because it hides the problem.

This is also the honest limit of browser-based AI agents on legacy work. They are good on modern SaaS. If your data lives in SAP GUI or a green-screen teller app, a browser agent cannot reach it at all. The accessibility-tree approach exists precisely because that is where the hard, unglamorous, high-volume work still sits.

Frequently asked questions