# RPA workflows (Preview)

> RPA with a coding agent: what RPA suits, how to brief a workflow, the role of UI Automation, and where human review matters most.

Robotic Process Automation (RPA) automates repetitive, rule-based work across the systems people use every day. With a coding agent, you describe the work in plain language and it produces a runnable workflow. Your part is to describe it well and review what comes back.

## What RPA is good for

RPA suits well-defined, deterministic work, especially where systems have no usable API:

- Reading and transforming files and spreadsheets.
- Moving data between systems and updating records.
- Calling APIs as part of a larger process.
- Driving desktop, web, and virtual applications through their interface.

When the work needs judgment rather than fixed rules, an agent, or a mix of both, may fit better. See [Agents](build-agents.md). When a workflow is one step in a longer process that spans approvals, systems, and time, a [Maestro Flow](build-maestro-flows.md) can orchestrate it alongside people and other automations.

For worked, end-to-end examples, see the [RPA recipes](examples-overview.md).

## What you can ask for

Building a new workflow is only the starting point. The same coding agent works across the whole life of an automation, so common requests include:

- **Building** a new workflow from a description, a set of manual steps, a process document, or a template such as the Robotic Enterprise Framework (REFramework).
- **Refactoring and extending** a workflow you already have, by restructuring it, adding a step, or swapping an activity.
- **Working in legacy projects**, recognizing older project types and operating within their constraints.
- **Adding tests**, generating test cases with assertions and running them to confirm behavior.
- **Reviewing** an existing automation for quality, missing error handling, and risky choices, without changing anything.
- **Debugging** a failing workflow by reading the error, finding the cause, and proposing a fix.
- **Packaging and reuse**, by publishing a project to Orchestrator or extracting shared logic into a reusable library.

You drive all of this in conversation, and the agent picks the right UiPath capability for each request behind the scenes.

## What makes a good RPA request

The agent builds what you describe, so the brief matters as much as it would for a colleague:

- The steps, in order.
- The systems and applications involved.
- The inputs and outputs, with their types.
- The screens or data the workflow touches.

The general guidance in [Working effectively](working-effectively.md) applies here too; the points above are what matter most for RPA. An existing process document is a strong starting point, as long as real customer data is removed first.

## Choosing low-code or coded

A UiPath RPA workflow can be built as a low-code workflow or as a coded one, and you guide which:

- **Low-code workflows** (`.xaml`) are the reviewable, auditable default. They have the widest activity coverage and can be edited in Studio Web. Most automations fit here.
- **Coded workflows** (`.cs`, C#) suit logic-heavy components, such as complex data transforms, parsing, or custom types.

Both can also be mixed in one project. Choosing the shape up front, rather than mid-build, avoids a restructure later; without direction, the agent defaults to low-code.

## Driving applications with UI Automation

The hardest and most valuable RPA work is driving an application's interface the way a person would, by clicking, typing, reading values, and moving through screens, for systems that offer no API. UiPath's UI Automation is what makes this reliable, and a coding agent uses it directly.

### How it captures the interface

Rather than guessing how to find each element, the agent explores the application at design time: it captures the screen, identifies the elements to act on, and builds the steps to navigate and fill them. This is multi-modal by design, because for desktop applications the underlying page structure is not enough on its own. Elements can be off-screen, scrolled out of view, or hidden behind a popup.

Captured elements are stored as stable targets in an **Object Repository**, so the same button or field can be reused across workflows and maintained in one place. This is what separates dependable UI automation from brittle, coordinate-based screen scraping.

### Staying resilient

Interfaces change, and UI Automation is built to absorb that:

| Capability | What it does |
| --- | --- |
| Selector healing | Adapts a target when the interface shifts, rather than breaking outright. |
| Diagnosis | Reads logs, recordings, and screenshots after a failure and explains what went wrong in plain language. |
| Screenplay | UiPath's AI-powered computer vision; adapts to the application and data at runtime, as a fallback on critical paths for unpredictable screens. |

### When there is no live application

If the target application is not available to capture against, the agent still produces the real workflow, leaving each interaction marked for a developer to finish the capture in Studio. Generated selectors are best treated as drafts either way, and confirmed against the real application.

UI automation is also the most expensive kind of RPA to build. It takes more time and effort than file, data, or API work, so an API is the better path wherever one exists, and time and effort are worth budgeting for.

## RPA conventions worth capturing

RPA projects have house rules worth stating once in a [context file](agent-context-files.md), rather than repeating them every session. Common examples:

- Modern design activities rather than the classic set.
- UI activities kept inside a Use Application/Browser scope.
- Native activities in preference to Invoke Code.
- Existing configuration files and recorded workflows left intact rather than overwritten.

## Strengths and limits

Coding agents are strong at greenfield, well-structured RPA and at the first version of a workflow. They are weaker, and need closer review, on:

- Complex or fragile selectors.
- Bespoke enterprise connectors.
- Unusual activity choices, where a generic fallback can creep in.

For what to check before accepting a workflow, see [Reviewing and validating output](reviewing-agent-output.md).

## More prompts to try

- Create a new RPA project from the REFramework template called `BankStatementReconciliation`.
- Create an RPA workflow that downloads attachments from the latest Outlook email matching subject "Invoice" and saves them to `./inbox/`.
- Add a Try Catch around the Submit Order step so business exceptions are logged and the transaction is set to Failed.
- Validate this project and fix any analyzer warnings.

## Go deeper

For the full picture of building automations with Studio and activities, see the [Studio documentation](https://docs.uipath.com/studio) and the [Activities documentation](https://docs.uipath.com/activities).