UiPath Studio, Attended and Unattended Robots, and Orchestrator Explained for Finance Teams

UiPath is a robotic process automation platform, and its documentation uses a handful of terms that finance teams hear in every project meeting: Studio, attended and unattended robots, and Orchestrator. This guide explains what each one is, as UiPath's own documentation describes it, and how they fit together in a finance setting. It builds on, and does not repeat, our general explainer on robotic process automation for accounting and finance. UiPath documentation is versioned and the pages we read did not show a last-updated date, so we cite the product version shown on each page. Menus, names and capabilities change between versions and with the type of deployment, so check the current documentation for yours. This article does not cover pricing or licensing.

UiPath Studio: where automations are built

The Studio user guide (Standalone, version 2024.10) describes Studio as the central development environment for building automations in the UiPath product family. Developers and business users use it to build automations that are published to Orchestrator and run by the Robot. The page says Studio supports low-code automations, built with a visual drag-and-drop interface, and coded automations written in code, and that you can build attended, unattended and testing automations. It also mentions a separate product, StudioX, aimed at business users with little or no coding experience.

The documentation describes the flow in three steps. Activities are assembled into workflows in Studio, the Robot executes those workflows, and Studio publishes them to Orchestrator. For a finance reader, the useful idea is that the process is designed once, in Studio, and run many times elsewhere. That makes the design document, the version published and the person who approved it the things to keep track of.

The Robot: the part that does the work

The Robot administrator guide (Standalone, version 2024.10) describes UiPath Robot as a software execution agent that carries out the workflows built in Studio, interacting with applications much as a human user would. It distinguishes the Robot, which performs the task, from the automation, which is the programmed task itself.

Attended and unattended: the key difference

The documentation draws the main line between two modes:

• Attended: a user starts the automation, it usually needs some human interaction, and it runs on the user's machine. The UiPath Assistant lets the attending user manage and run automations. UiPath's overview page describes attended automations as running under human supervision and suiting smaller, fragmented tasks, with the example of submitting an expense report. The user supplies their own login credentials, and the automation must not perform actions the user could not perform themselves.
• Unattended: Orchestrator manages it and it runs independently, with no human user present, usually on dedicated machines connected to Orchestrator. The overview page describes these as suited to complex, highly repetitive tasks, usually run in batches according to predefined rules, with no human user present, and able to perform privileged operations. Credentials come from credential assets configured by an Administrator, so developers can reference credentials without holding them.

The Robot administrator guide (version 2023.10) adds that an attended robot acts as a personal assistant, with the end user deciding when and how it runs, while unattended robots are not user-dependent and are controlled through Orchestrator. It also says that attended robots run on the machine where the user does daily work, while unattended robots run on Orchestrator-connected machines, usually dedicated ones.

Orchestrator: the control room

The Orchestrator introduction describes it as a web application for coordinating the processes and robots that run repetitive business processes. The page lists these main capabilities:

• Provisioning: creating and maintaining connections between runtimes, robots and the web application.
• Deployment: delivering the correct package versions to assigned runtimes and robots.
• Configuration: maintaining and delivering runtime and robot environments and process configuration.
• Queues: distributing workload automatically across runtimes and robots.
• Monitoring: tracking execution identity data and maintaining user permissions.
• Logging: storing and indexing logs in an SQL database, Elasticsearch, or both.
• Inter-connectivity: acting as a central communication point for third-party solutions and applications.

The page also explains that for unattended automation Orchestrator launches executions on demand or in a preplanned manner with triggers.

Jobs and triggers

The Jobs page (Orchestrator, cloud documentation) defines a job as the execution of a process on a UiPath Robot. It says attended robots cannot run jobs from Orchestrator except for debugging or development. Unattended jobs can be launched manually from the Jobs or Processes page, or through triggers; the page names time, queue, event and API triggers. A job can wait in a pending state until the resources it needs, such as matching credentials or a free robot, are available. The Jobs page is also where launched jobs are monitored, with details and logs, and where they can be stopped, killed, resumed or restarted.

Queues: how work gets shared out

Finance processes often work through a list of items, such as invoices to enter or payments to check. The Orchestrator queues documentation (version 2024.10) describes a queue as a container for items, which become transactions once processed. It describes this processing order: items with a deadline are processed first, by priority and then by deadline, and items without a deadline are processed by priority and then first in, first out. The page also covers retries and review: failed or abandoned items can be assigned to a reviewer, and changes are tracked in a history tab. It mentions options such as schema validation, unique references and queue SLA predictions. It also states a size limit for the specific data held on each item and suggests storing large data externally.

Putting it together for a finance team

A simple mental model of our own may help. Studio is the drawing board, Orchestrator is the control room and the robots are the workers, either sitting beside a person (attended) or working on their own machines (unattended). The following suggestions are ours, not UiPath requirements:

• Match the mode to the task. A task that needs a person's judgement mid-way suits attended automation. A rule-based batch with no judgement points is a candidate for unattended.
• Treat robot credentials like staff credentials. Know who administers credential assets, who can run which process, and what each robot is permitted to touch. This is where a security awareness programme helps; see our guide to cybersecurity training for finance professionals.
• Check the inputs. A robot will faithfully process poor data. Data quality controls upstream are covered in financial data quality management.
• Plan for exceptions. Decide who reviews failed queue items and how quickly.
• Keep records. Retain the process design, the version published and the change approvals alongside the logs Orchestrator keeps.

Our suggestion: if personal data passes through a process, involve the person responsible for data protection before go-live. This article does not cover legal requirements.

Learnsignal's offices are off Baggot Street in Dublin, and we offer in-person training from there. For current details, see our CPD pages.

Frequently asked questions

What is the difference between an attended and an unattended robot?

According to UiPath's documentation, an attended robot is started by a user and runs on the user's machine, while an unattended robot is managed by Orchestrator and runs independently, usually on dedicated machines connected to Orchestrator.

What does Orchestrator do?

UiPath describes it as a web application for coordinating processes and robots, with capabilities including provisioning, deployment, configuration, queues, monitoring and logging.

Do attended robots need Orchestrator to start jobs?

The Jobs page says attended robots cannot run jobs from Orchestrator except for debugging or development. Attended automations are triggered from the UiPath Assistant or the Robot command line.

Where do unattended robots get their credentials?

UiPath's overview says credentials come from credential assets configured by an Administrator, so developers do not need to hold them.

Is this guide current for my version?

The pages we read cite versions 2023.10, 2024.10 and the cloud documentation, and show no update dates. Check the documentation for your version before relying on a detail.

In short: Studio builds, the Robot runs and Orchestrator controls, and in finance the careful part is credentials, inputs and exception handling.