RPA harness

An RPA harness is the control layer around a robotic process automation bot. The bot performs a task; the harness supplies its inputs, controls execution, checks the result, and decides what happens when something fails.

Our view is simple: automate repetitive steps, verify the results, and keep people in control of important decisions. This guide describes that architecture, rather than a particular product API.

What belongs in the harness?

Validated inputs. Define the job, required fields, expected files, and permitted actions before opening an application. Reject incomplete work rather than guessing missing values.
Controlled execution. Give each run a job identifier, a time limit, and the permissions it needs. Keep credentials separate from job data and avoid sharing mutable sessions between unrelated jobs.
Observable progress. Record which step ran, its outcome, and a useful error when it failed. Redact sensitive values from logs and screenshots; collect only the evidence needed to diagnose the run.
Result checks. Check the business outcome, not just whether a button was clicked. An exported file should have the expected columns and reporting period; a submitted record should have a confirmed identifier.
Bounded recovery. Retry only when the operation is safe to repeat. Save checkpoints and stop for human review when the outcome is uncertain or the next action requires approval.

Example: exporting a weekly report

Suppose a desktop bot signs in to a business application and downloads an inventory report. A minimal harness accepts the reporting date, starts the bot with a deadline, and checks the downloaded artifact before declaring success.

{
  "job_id": "inventory-report-2026-09-07",
  "input": { "report_date": "2026-09-07" },
  "timeout_seconds": 120,
  "max_attempts": 2,
  "checks": [
    "file_exists",
    "expected_columns",
    "reporting_period_matches"
  ],
  "on_uncertain_result": "human_review"
}

This is illustrative configuration, not an executable Emplode API. The chosen timeout and attempt limit are example values; set them from the actual workflow and its risks.

If a download times out, first check whether the file already arrived. A retry should not silently overwrite a verified output. If the application is showing the wrong reporting period, fail the validation and retain a redacted diagnostic instead of marking the job complete.

Bot, test harness, or production harness?

The RPA bot contains the steps: navigate, fill fields, download, or submit. It knows how to perform the workflow.

A test harness exercises that workflow with controlled inputs and assertions, preferably against test data or a non-production environment. It helps detect regressions before release.

A production execution harness supervises real jobs. It needs access control, operational limits, audit evidence, and recovery rules appropriate to actual side effects. Test assertions are useful here, but a passing test is not a substitute for checking a live result.

Before running unattended

Define a measurable success condition and explicit failure states.
Test expired sessions, changed screens, missing inputs, and partial completion.
Distinguish a safe retry from an action that could create a duplicate record.
Require human approval before sensitive or irreversible changes.
Document who receives failures and how a stopped job can be resumed safely.

A harness cannot make every interface change or authentication problem disappear. Its purpose is to make those failures visible, bounded, and recoverable instead of allowing silent mistakes.

Implementation references

For concrete platform mechanisms, see Microsoft's error handling for Power Automate desktop flows and Playwright's assertions for browser automation tests. These are implementation examples, not requirements to use a particular tool.