What is RPA?

RPA exists because many systems have no usable API. An old finance application, a supplier portal or a terminal-based mainframe screen may only be reachable the way a person reaches it. A bot can work those screens all day, so organisations can automate data entry and copying between systems without waiting for the application to be replaced.

The same strength explains the weakness. A bot depends on the screen staying the same. When a field moves, a pop-up appears or a page loads slowly, the bot can fail or, worse, type into the wrong place. Teams that run many bots usually spend real effort maintaining them, so RPA works best for stable screens and predictable input.

A developer or trained business user builds the bot in a designer, either by recording their own actions or by assembling prebuilt actions such as open application, click element, read cell and type text. Microsoft's documentation for Power Automate desktop flows describes exactly this: drag-and-drop actions or recording, with the bot working through application UI elements, images or screen coordinates, including legacy applications such as terminal emulators.

Bots run in two modes. UiPath describes attended robots, which work alongside an employee and assist with their tasks, and unattended robots, which operate on their own without a person watching. Attended bots suit tasks inside one person's day; unattended bots suit back-office batches.

An orchestration layer schedules unattended bots, hands them work from a queue, stores the credentials they sign in with and keeps logs of each run. When a bot meets something its rules do not cover, it stops or passes the item to a person.

A distributor receives orders in a web portal but must key each one into an older order-entry application that has no API. An unattended bot runs on a schedule. It exports the new orders from the portal, opens the legacy application, signs in with its own service account, and for each order fills in the customer code, product codes and quantities, then saves and reads back the confirmation number.

The bot writes each confirmation number back to the portal and logs any order it could not enter, for example because a product code was not recognised. A person handles that exception list each morning. When the legacy application's next update moves the quantity field, the bot must be fixed before it runs again, which is the maintenance cost RPA owners plan for.

Swfte is not an RPA vendor. Studio workflows call tools and APIs; they do not operate a desktop screen, record clicks or run software robots. If the only way into an application is its interface, keep an RPA tool for that step.

Where Studio does fit is the work around the bot: steps that have APIs, steps that need reading free text such as an email or a contract, and decisions that should go to a named person through an approval step. The RPA alternative page sets out which steps belong where, and how to move judgement-heavy bot work to agents without retiring the bots that still do their job.

• RPA alternative: agents and workflows compared with bots
• Swfte Studio

Definitions on this page were read on the sources below on 7 October 2026. Where sources define the term differently, the page says so. The full glossary lists more terms.