UiPath Documentation
maestro
latest
false
Maestro user guide

Human

Human node for pausing a process and assigning a task for human review, approval, or input.

The Human node pauses the process and assigns a task to a person, then resumes the process once they complete it. Use it when a process needs human review, approval, or input before it can continue.

When to use Human vs Decision

Use the Human node when a person needs to review information and respond before the process continues. Use the Decision node when the branch can be resolved automatically from existing data, without human involvement.

The Human node routes on the assignee's chosen outcome through its own output handles. Reach for a Decision when the branch follows from existing data instead of a person's choice.

Human node types

The task presented to the human can be created via two mechanisms: Quick form and Action app.

Quick form

Build and debug a lightweight form directly on the node. You define the fields the assignee sees, the inputs they need to provide and the outcomes they can choose. This is the default and the best fit for approvals and straightforward data collection.

Action app

Action apps provide a richer, fully customized interface for the task assigned to the human. They can be built visually in UiPath App Studio or Studio Web, or as a Coded Action App—a custom React or Angular application. A coded app is selected under Action App, and its inputs are mapped at configuration time. Refer to About Coded Action Apps.

Quick formAction app
UI definedOn the node, versioned with the processSeparate app, deployed to Orchestrator
Reuse across processesYes, by copying and pasting JSONYes
CostNo additional units, no Apps dependencyRequires app deployment
LayoutAllows multi-column, multi-width layouts, Field behaviorFull control
Data at render timeBound process variables/expressions onlySDK: assets, buckets, connections, Data Fabric, trigger processes
TestingInline debug from canvasBuild → deploy → run
Build skills requiredNoneApp Studio, or React/Angular for coded Apps
Tip:

Start with a Quick form. Move to an Action app when you need to reuse the same interface across processes, show data the process does not already carry, or build a UI a form cannot express.

Building the app itself is covered in the Action Apps documentation. From this point onward, this page covers the Quick form task type. For a hands-on walkthrough, refer to Add human approval to a workflow.

Configuration

FieldRequiredDefaultDescription
Assignment criteriaYesSingle UserControls how the Human node picks the person who gets the task. Choose between Single User, All users, Round Robin, Workload, or Custom.
SchemaYesSubmit outcomeForm structure, including fields the assignee sees or fills in and outcomes they can select. Refer to Schema for the full structure.
Delivery ChannelsSet at tenant levelRead-only on the node — the available channels are inherited from tenant-level configuration and shown as disabled checkboxes. Refer to Delivery channels for details.
Task titleNoNoneTitle shown to the assignee in their task list.
PriorityNoNonePriority shown in Action Center: Low, Medium, or High.
LabelsNoNoneComma-separated labels for organizing tasks, for example finance,approval.

Assignment criteria

Assignment criteria controls which person or people receive the task. Selecting a criterion changes the second field to match — a user picker for Single User, a group picker for the group-based criteria.

CriteriaWho gets the taskUse it when
Single UserOne named person.A specific individual owns this decision — a named approver, a single reviewer
All usersEvery member of the group at once. The first person to complete it closes the task for everyone.You care about speed over ownership. Whoever is free picks it up
WorkloadThe one group member with the fewest open tasksYou want the queue spread evenly across a team
Round RobinGroup members in turn, cycling through the membership listYou want each member to take an equal share regardless of how fast they work
CustomThe member with the fewest open tasks, chosen from a list of users you supply at runtime rather than from a group's full membership.Eligibility changes per run — skipping people who are out of office, off shift, or outside the right role or region.

Requirements and limits

Important:

Workload and Round Robin require a local group. Active Directory groups are rejected for both. Use Single User or All users if your assignees are in an Active Directory (AD) group.

In debug, group assignment does not work from a personal workspace. Debug runs create the task in your personal workspace, which group members cannot access — so the task is created but stays Unassigned, and no notifications go out. This is expected, not a defect. Deploy the solution to a shared folder to test group assignment properly. Single-user assignment works normally in debug.

Errors you may see:

ErrorMeaning
NoUsersFoundInLocalGroupThe selected group has no members.
NoEligibleUsersFoundInGroupEvery member was excluded, so there is nobody left to assign to.

Schema

The Schema defines what the assignee sees and what they return to the process. It has two parts: fields and outcomes.

Fields

The Schema can also be edited directly as JSON. Refer to Quick Form tasks for the full JSON schema reference. In the Form view, each field has these settings:

SettingWhat it does
LabelThe display name shown to the assignee.
TypeControls validation and how the input renders. Available types: Text, Number, Decimal number, Date, Date and time, Yes or no, Single select, Multi-select, Array, File.
BindingAn expression that pre-populates the field, for example $vars.requestAmt. Accepts any workflow expression, not only a variable reference.
EditableThe padlock next to the value. Locked means the assignee can read the value but not change it.
VariableShown as an (x) badge next to the field name. Auto-derived from the Label for Output and In/Out fields, exposing the value as a named process variable in addition to $vars.<nodeName>.output.<fieldId>. Not present on Input fields.
Field directions

Fields carry data into and out of the task. Each field has a direction.

  • Input fields are read-only context for the assignee, bound to a process value, for example $vars.start.output.employeeName.
  • Output fields are filled in by the assignee and returned to the process.
  • In/Out fields do both: they show the assignee a process value as a starting point, and the assignee can edit it before it's returned to the process.

A field's direction is not a separate setting. It is the result of two controls: whether the field is bound determines if it arrives pre-filled, and whether it is unlocked determines if the assignee can change it.

BindingPadlockDirectionAssignee seesEditable & returned
SetLocked 🔒InputThe bound valueNo
SetUnlocked 🔓In/OutThe bound valueYes
NoneUnlocked 🔓OutputAn empty fieldYes
NoneLocked 🔒Not validAn empty fieldNo

Outcomes

Outcomes are the buttons the assignee uses to complete the task, for example Approve and Reject. The default schema has a single Submit outcome. The first outcome is marked as the primary action.

Each outcome adds its own output handle to the node. When the assignee selects an outcome, the process continues from that outcome's handle, so you can route each outcome to a different path. Refer to Branching on the result.

Delivery channels

Tasks are delivered to:

  • Action Center
  • Email
  • Slack
  • Microsoft Teams
Important:

Delivery channels can only be modified at the tenant level, from Admin settings. The checkboxes on the node are disabled and reflect the current tenant configuration.

Slack and Microsoft Teams require an Integration Service connection. Refer to Actionable notifications for connector setup.

Output

Access the node's output at $vars.<nodeName>.output and the selected outcome at $vars.<nodeName>.status.

output

The task result: an object holding the values the assignee submitted, keyed by output field. Read a single field with $vars.<nodeName>.output.<fieldId>. The object also carries an Action property set to the selected outcome.

status

The outcome the assignee selected, for example Approve. Branch on this value to route the process.

Branching on the result

Each outcome you define adds an output handle to the Human node. When the assignee completes the task, the process continues from the handle for the outcome they selected. Connect each outcome handle to the node that should run for that path. You don't need a Decision node to split on the outcome.

Human
  ├─ Approve → continue processing
  └─ Reject  → notify the requester and terminate
Human
  ├─ Approve → continue processing
  └─ Reject  → notify the requester and terminate

Read a submitted field in any downstream node with $vars.<nodeName>.output.<fieldId>:

// In a Script node on one of the outcome paths
return $vars.approval.output.comment;
// In a Script node on one of the outcome paths
return $vars.approval.output.comment;

The selected outcome is also available as $vars.<nodeName>.status if you need it in an expression.

Common issues

Task does not appear for the assignee

Verify the assignee, whether a user or a group, is correct and has access to Action Center.

An output value is missing

Confirm the field is defined in the Schema with direction Output.

An outcome routes to the wrong path

Confirm each outcome's output handle is connected to the node you intend. Each outcome you define in the schema has its own handle on the Human node.

Notes

Note:

To test without a real assignee, use Mock output to simulate a status and output response. Refer to Add human approval to a workflow for the steps.

  • If the assignee is a group, any member of that group can claim and complete the task.
  • For a richer interface than a form, back the task with an Action app instead of a Quick form.

Was this page helpful?

Connect

Need help? Support

Want to learn? UiPath Academy

Have questions? UiPath Forum

Stay updated