A software robot is a program that performs rule-based work in business applications by operating them the way a person would: reading screens, clicking buttons, typing into fields, opening files and moving data between systems. In RPA (robotic process automation), the software robot, often called an RPA bot, is the unit that actually executes an automated process, while design tools and orchestrators create, schedule and supervise it.
Despite the name, a software robot has no physical form. It is a defined workflow running on a desktop or virtual machine under a dedicated identity, and its value lies in automating processes that span applications without suitable APIs, such as legacy terminals, desktop clients and web portals.
How a software robot executes work
A software robot runs a workflow definition: an ordered set of activities with conditions, loops and exception handlers, built in a visual designer or recorded from a user session. At run time, the robot launches applications, locates interface elements with UI selectors, reads or writes values and follows business rules encoded in the workflow.
Robots interact with applications through several layers. The most reliable is the accessibility or object layer, where the robot addresses a control by its attributes. When that is unavailable, as on remote desktops, it falls back to image recognition and OCR, which is slower and more fragile. Where an application offers an API or a database, mature teams let the robot call it directly instead of driving the screen.
| Method | How it finds data | Reliability | Typical use |
|---|---|---|---|
| Selector-based UI | Control attributes and hierarchy | High | Web and desktop apps |
| Image and OCR | Pixel matching and text recognition | Low to medium | Citrix and remote sessions |
| Keyboard emulation | Keystrokes and screen positions | Medium | Terminal emulators |
| API or database call | Structured interface | Very high | Systems with integration access |
Attended and unattended software robots
Software robots operate in two main modes. An attended robot runs on an employee’s own desktop and is triggered by that person, assisting with steps inside a task. An unattended robot runs on a dedicated machine, usually a virtual one, starts from a schedule or a queue, and works without human presence, often around the clock.
| Aspect | Attended robot | Unattended robot |
|---|---|---|
| Trigger | User action or hotkey | Schedule, queue or event |
| Machine | Employee workstation | Dedicated virtual machine |
| Identity | Runs as the user | Own robot account |
| Typical tasks | Customer call support steps | Back-office batch processing |
| Licensing basis | Per user, usually | Per robot or runtime, usually |
A hybrid model lets an attended robot hand work to an unattended one, for example when an agent collects data on a call and a back-office robot completes the transaction later. Platforms such as UiPath, Automation Anywhere, Blue Prism and Power Automate for desktop support both modes, with differences in terminology and licensing.
The software robot within an RPA platform
A robot rarely works alone. A bot orchestrator assigns jobs, distributes work items from queues across several robots, stores credentials and collects logs. A credential vault supplies passwords at run time so they never appear in the workflow. Work queues allow horizontal scaling: adding robots raises throughput as long as the target applications can handle the extra sessions.
Each unattended robot should have its own non-personal account with the minimum permissions needed. Sharing a human user’s account obscures the audit trail and breaks when that person changes a password or leaves.
Robots also depend on a controlled runtime environment. Unattended machines need fixed screen resolution, consistent language and regional settings, and the same application versions as the development environment. Teams typically keep separate development, test and production robot environments and promote workflow packages between them, so that a change can be tested against realistic screens before it touches live data. Logs from every run are retained for audit and for diagnosing failures after the fact.
Choosing tasks for a software robot
Software robots fit tasks that are rule-based, repetitive, high-volume and stable, with digital and structured inputs. They fit poorly where judgment, unstructured documents or frequently changing screens dominate, unless they are combined with document processing or AI components.
| Process trait | Good candidate | Poor candidate |
|---|---|---|
| Rules | Clear and documented | Depend on judgment |
| Inputs | Structured, digital | Handwritten or free text |
| Volume | Hundreds of cases per week | A few cases per month |
| Application stability | Interfaces change rarely | Frequent redesigns |
| Exceptions | Below about 10 to 20 percent | Majority of cases |
Task mining and process mining help identify candidates by measuring how often steps repeat and how much they vary. A realistic business case counts maintenance effort, not only the hours saved, because robots need updates whenever target applications change.
Limitations and failure modes of software robots
The central weakness of a software robot is dependence on the user interface. A renamed button, a new pop-up, a slow page load or a changed screen resolution can stop a run. Robots built on fixed coordinates or fixed delays are especially brittle, and screen scraping of remote sessions adds further uncertainty.
- Selector breakage after application updates, requiring rapid maintenance.
- Timing failures when fixed waits are used instead of waiting for elements.
- Silent errors when exceptions are swallowed rather than logged and escalated.
- Shadow bots built outside governance with personal credentials.
- Automating a broken process instead of simplifying it first.
Good practice includes explicit exception handling that separates business exceptions from system exceptions, retry logic for transient faults, screenshots on failure and a monitored queue for cases that need human attention.
Stripped to the essentials
A software robot is a digital worker that uses programs the way a person does. It opens the same windows, types into the same boxes and clicks the same buttons, only faster and without getting tired.
It is excellent at boring, repetitive tasks with clear rules, such as copying order details from emails into an accounting system. It struggles when a screen suddenly looks different or when a decision needs common sense, so people still design, watch and fix it.
Where it is applied
An insurance back office receives about 1,200 address change requests each week. Staff had to copy each change from a web form into a policy administration system on a legacy terminal and then into a separate billing application, which took around four minutes per request.
The automation team deployed two unattended software robots on virtual machines. They read requests from a queue, update both systems through selectors and terminal keystrokes, and send any case with a missing policy number to a human review queue. After stabilization, most requests were processed within an hour of arrival, and staff focused on the exceptions that needed judgment.