Workflow automation tools split by surface, not by feature count.

The four surfaces, named honestly

Every tool sold under the “workflow automation” label reaches into one or two of four surfaces. The categories are the honest taxonomy that the listicles paper over with a unified comparison grid.

Cron and polled triggers. The smallest surface. The tool fires on a schedule or on the appearance of a file or an email. Apache Airflow, GitHub Actions cron, n8n's schedule trigger, and the “new email matches X” trigger inside Zapier are the same shape. Anything that can be expressed as “run this script when this thing happens on the clock or in a known queue” lives here.

Public API orchestration. The next surface up. The tool's input vocabulary is the union of the connectors its vendor has built. A workflow is a directed graph of API calls plus the conditional logic between them. Zapier, Make, n8n, Workato, Pipedream, and Power Automate Cloud all live here. The defining constraint is that every step has to map to an HTTP request the vendor has wrapped, and the cardinality of the connector library is the load-bearing differentiator within the category.

Browser DOM and rendered web. A surface visible only when an action requires a rendered Chromium tab. Skyvern, Browser Use, CloudCruise, and the “web agents” flavor of recent AI products live here. The bundled cost is the anti-bot fabric (CAPTCHA solving, residential proxies, geo-targeting). The unit of work is one tab step.

OS-level desktop event stream. The widest surface, and the one most listicles either skip or fold under “RPA” without explanation. The tool reads what the operating system exposes through the same accessibility interfaces a screen reader uses. UiPath, Automation Anywhere, Blue Prism, Power Automate Desktop, and Mediar live here. The unit of work is a captured user action: a click, a typed value, a hotkey. This is the surface that lets a workflow include a SAP GUI window, an Oracle Forms session, an Epic Hyperspace chart inside a Citrix shell, or a Jack Henry green-screen, because the surface is the OS itself rather than any one application's API.

The keystroke-level spec that defines a step

Surfaces sound like marketing language until you ask each tool to publish what it thinks an automatable step is. An API-orchestration tool answers with a connector list. A browser-native agent answers with a list of DOM events. An OS-level recorder has a harder question to answer, because the input it receives is a raw human interface device stream and most of that stream is noise (mouse moves, modifier-less keystrokes that are part of a longer typed word, repeated key-down events from auto-repeat). The recorder has to publish a spec for what survives the filter.

Mediar's spec is in apps/desktop/src-tauri/src/workflow_recorder.rs, in a function called is_meaningful_event that lives at lines 252-316. The function is small enough to print in full, and printing it in full is the right move because the honest answer to “what counts as a step” is exactly this match expression and nothing more.

Read the array. The four virtual-key codes are the keys that count as a step on their own, with no modifier. Enter is 0x0D because it commits a form. Delete is 0x2E because it removes a row. Escape is 0x1B because it dismisses a modal. Tab is 0x09 because it moves focus, which on a SAP GUI screen is the difference between filling the next field and committing the wrong record. The letter a is not in the array because the recorder treats alphanumeric typing as part of a longer aggregated event called TextInputCompleted. Mouse moves and ordinary key-up events are dropped on the floor before they ever reach the matcher.

The point is that this is a published vocabulary the buyer can hold in their head. Seven event variants, four standalone keys, any modifier combo. That is the full spec for what an OS-level recorder on this product treats as “a step the user took.” A workflow on Mediar is a sequence of those, and nothing else. An API-orchestration tool literally has no way to write down that sequence, because the keystroke stream is not in its input channel. That gap is the entire reason a buyer with desktop workflows ends up on a different tool than a buyer with HTTP workflows.

The four surfaces, mapped onto a buying decision

The grid below restates the surface taxonomy as a head-to-head between an API-orchestration tool (the modal answer in this category) and an OS-level desktop tool (Mediar). The point of the grid is not to claim one always wins. It is to make explicit the axes that listicle comparisons usually elide.

Read the grid as a pair of constraints, not a scorecard. The API-orchestration column wins when every step is an HTTP call you have credentials for. The desktop column wins when at least one step is a window the user has to look at to do the work.

Where each category stops working

The honest version of a workflow automation guide names the failure modes by category. The dishonest version implies a feature matrix can rank one tool above another in a way that survives the user's first non-trivial workflow.

Cron and polled triggers fail when the trigger event is not on the clock and is not in a queue the tool can poll. A workflow that fires when a CSR drops a paper form on the front-office scanner is not a cron workflow. The right answer is to lift the trigger up to a higher surface (a polled file watcher on the share, an email rule, an OS-level recorder watching the application that opens the scan).

API-orchestration tools fail on any application that does not have a public API the buyer is willing to use. Most of the canonical legacy enterprise targets fall into this bucket: SAP GUI, Oracle EBS, Jack Henry, Fiserv, FIS, Epic Hyperspace, Cerner, mainframe terminal emulators. The API exists in some cases, but it costs more to license, requires a vendor engagement, or is gated behind a credentialing flow that the operations team does not have authority over. The API-orchestration tool is the wrong tool for that workflow not because it is bad software but because the surface is unreachable from where the tool stands.

Browser-DOM agents fail on every workflow that involves a window that is not Chromium. Skyvern, Browser Use, and CloudCruise are excellent on a hardened public web portal where the bundled anti-bot fabric is the load-bearing cost. They have no Windows desktop runtime, no Citrix runtime, no mainframe terminal connector. A workflow whose first step is a SAP order-entry screen is unrepresentable on a browser-DOM agent regardless of how much credit the buyer is willing to spend.

OS-level desktop tools fail on applications that genuinely expose nothing useful through Windows UI Automation: a small handful of custom OpenGL surfaces, some Java Swing apps in the default theme, a few legacy terminal emulators that paint their cells with raw GDI. Computer-vision RPA can sometimes reach those surfaces by reading pixels directly. The honest move is to admit the failure mode and pick the right tool. Most legacy systems Mediar's customers care about (SAP GUI, Oracle EBS, Jack Henry, Fiserv, FIS, Epic, Cerner) do publish dense and stable accessibility trees, because their vendors have to maintain them for assistive-technology compliance reasons.

A short selection rule, written down

Walk the workflow with a stopwatch. Label every step by the surface it lives on. Add up the time per surface. The right tool is the one whose surface covers the largest time-weighted slice of the workflow, with two adjustments. First, if any single step is on a surface only one category can reach, the tool has to be in that category, no matter what the time-weighted breakdown says. Second, if you find yourself building a Rube-Goldberg pipeline that hands the workflow off between three tools, the right answer is almost always to move the entire workflow up to the wider surface and let the wider tool handle the cheaper steps too. Wider tools have always been able to imitate narrower ones; the reverse is structurally impossible.

That is the whole rule. It is shorter than every comparison matrix on the topic, and it is the only one that survives the first time a buyer's actual workflow does not fit the matrix the listicle published.

Questions a buyer eventually asks