To automate SAP data entry, you mostly need to get the failure path right. The clicks are the easy part.

The thesis, plainly

Most existing material on this topic answers the question how do I get a robot to type into SAP. That is the question to ask once. After it is answered, the question that decides whether your automation queue runs unattended or burns an analyst hour every morning is how does the queue behave when the type fails.

The shape of an SAP queue is that ninety-something percent of runs succeed without anyone looking at them, and the bottom few percent contain the entire operating cost of the system. If those failures all wake a human, you have not automated SAP data entry; you have built a ticket factory. If those failures get retried indiscriminately, you eventually post a duplicate journal and have a real audit conversation. The middle path is a classifier that knows which kind of failure is which.

That classifier exists in the Mediar codebase as a 230-line Rust file at crates/executor/src/config/retry.rs. The rest of this page reads it.

The classifier, in one function

The function is called classify_error. It takes one argument, the lowercase error message, and returns one of three enum variants: Infrastructure, WorkflowLogic, or Unknown. Two arrays of substring patterns drive the match. There is no regex, no model, no protocol-specific wrapper. The whole policy is legible in a single screen of code.

That choice is deliberate. SAP returns text into a status bar, the Windows accessibility runtime returns text from a node, and the MCP transport layer returns its own. A classifier that operates on the flattened lowercase string handles all three without a wrapper per source. The cost is that adding a pattern is a code change, which is the right side of that trade for an executor that has to be conservative.

The categories, mapped to SAP failures

Reading the classifier as patterns is one thing. Reading it as the failure modes a working SAP queue actually produces is another. Here is the map: every left-column entry below corresponds to a substring branch in retry.rs, and every right-column entry is the SAP-shaped failure that surfaces it.

One real run, traced through the layer

What the classifier does is easier to read in a trace than in prose. The output below is the shape of an SAP run that hits two different failure classes back to back: an Infrastructure error that the queue retries through, and an Unknown error that the queue refuses to retry and hands to the analyzer instead.

Two things to note. First, the retries on the Infrastructure branch are silent: nobody is paged for a connection reset that self-heals on the second attempt. Second, the Unknown branch does not retry at all. Element not found after the Infrastructure retries are exhausted is the signal that something changed in SAP, and pounding the queue at it would not help. The executor stops, the analyzer takes over, and a human ack is required before the queue moves.

What an SAP error actually flows through

The runtime sits between the SAP-side error sources and three possible terminal outcomes. The diagram below is the live shape: three input channels surface text into a single classifier, and the classifier hands the run to one of three downstream paths. Two of those paths are silent; the third pages a human.

The diagram exists because the two bits of code that decide which path a failure takes (the classifier in retry.rs, the analyzer route in apps/web/src/app/api/internal/analyze-error/route.ts) live in different services in the monorepo, and reading them in isolation hides the fact that they form one decision surface. Together they define the policy a SAP automation team operates under in production.

The model only enters on the failure path

The escalation layer runs in a separate route at apps/web/src/app/api/internal/analyze-error/route.ts. When the deterministic retries are exhausted on a SAP run, the executor posts the failed execution's error, logs, and result payload to that route. The route loads gemini-2.5-flash through Vertex AI, hands it a prompt scoped to the OneDrive-to-SAP workflow, and asks for a structured analysis with four named sections: Root Cause, Impact, Solution, and Prevention.

The prompt itself names six common failure categories that the model is told to look for. Reading the prompt as a checklist of what an SAP automation actually fails on in the field is the most direct way to ground the categories above:

Two things make this design choice load-bearing. The model runs after the deterministic retries, not before any of them. And the model writes a note that lands in the dashboard next to the failure, but it does not click anything in SAP. It cannot retry a journal post on its own. The human is still the only path back into the queue, and that is on purpose: a regulated G/L is not the place to discover what an autonomous agent will do under pressure.

Why volatile-attribute stripping is the SAP-specific trick

One pattern in the classifier is conspicuously absent: position changed. SAP repaints constantly. A support pack nudges a field down a row, a screen variant rearranges a tab, a customer-specific variant adds a column. Selector-based RPA categorizes most of those as element not found because the recorded selector tied itself to a coordinate or a tree position. The result is a queue that fails for cosmetic reasons and pages a human for nothing.

The Mediar runtime sidesteps this with a small file at apps/desktop/src-tauri/src/dom_tree_diff.rs. Before two captured trees are compared, the function remove_volatile_dom_attributes walks the JSON and drops every x, y, width, and height field, plus the value field on input elements (which is captured separately in the event stream and would otherwise dominate the diff with noise). What is left is the structural shape: roles, ids, names, types, text content.

The SAP-specific consequence is that a layout shuffle does not fire a diff, which means it does not produce an Unknown error, which means it does not page anyone. The classifier never sees it. The queue keeps moving. That is the part of the system that makes the math work for an SAP shop running 200 posts a day on a vendor cadence that ships meaningless layout updates every two months.

What this buys an SAP team in practice

The argument has been technical so far. The operational version is shorter. An SAP automation queue with this exception-handling layer behaves like a junior analyst who follows three rules: retry the network once and never tell anyone, escalate anything SAP itself rejected, and stop cold on anything novel. That is the shape that turns an SAP automation pilot into a system the finance team trusts to run unattended overnight, because it exposes the right failures and silences the noise without covering up the dangerous failures.

What it does not buy you is autonomy on the failure path. Designing for autonomy on a journal entry that touches the G/L would be a different product, and it would be a worse one for the regulated SAP buyer. The point of the layer is to make the remaining human attention as cheap as possible, not to remove it.

The honest place to start, if this argument is interesting, is to bring one SAP transaction and one realistic failure mode and watch the layer work on it.

When this design is the wrong fit

A few cases where the conservative do-not-retry posture is not what you want.

Read-only SAP scraping. If the workflow only reads from SAP (a daily extract for a dashboard), retrying liberally on Unknown errors is fine and the conservative default is overcautious. The classifier is configurable; bumping max_infrastructure_retries on a read workflow is a one-line change.

Idempotent posting against a unique key. If the upstream system supplies a deterministic external key and SAP rejects duplicates on it, an aggressive retry is safe. Most journal entries are not in this shape, but a few line-item interfaces are. For those, the do-not-retry default is leaving throughput on the table.

High-volume bulk loads. A 40,000-row chart-of-accounts load is what LSMW or a properly tuned BAPI queue is built for. The exception-handling shape on this page is built for the steady stream of event-driven posts (a PDF arrives, post it; a row appears, post it), and it is honest to say it is not the right answer for the once-a-quarter migration.

Frequently asked questions