- Getting started
- Activities
- Designing long-running workflows
- Start Job And Get Reference
- Wait For Job And Resume
- Add Queue Item And Get Reference
- Wait For Queue Item And Resume
- Wait For Form Task And Resume
- Resume After Delay
- Assign Tasks
- Create External Task
- Wait For External Task And Resume
- Complete Task
- Forward Task
- Get Form Tasks
- Get Task Data
- Get App Tasks
- Add Task Comment
- Update Task Labels
- Create App Task
- Wait For App Task And Resume
- Configure task timer
- Actions
- Autopilot in Action Center - Preview
- Processes
- Notifications
- Audit
Quick Form tasks, inline human-in-the-loop forms for Maestro, Case Management, Flow, and Agents, with no separate app to build.
Quick Form tasks let you define a human-in-the-loop (HITL) review step directly inside your process. No app to build, no separate deployment, no additional cost or units. The form schema lives in the process itself, and the form appears in Action Center for the assigned reviewer when the task runs.
Quick Form tasks work across all UiPath process surfaces: Maestro BPMN, Case Management, Flow, and Agents.
Form and JSON views
The form schema is opened differently depending on where you build it:
- In Maestro BPMN and Case Management, the schema is a file in the process. A Customize schema button in the task node's properties panel opens it in a dedicated schema editor within the canvas workspace. Once a schema exists, the button reads Edit schema.
- In Flow, the schema editor is inline in the node's properties panel, with no file and no separate launch step.
Both editors offer two views, switched with a Form / JSON toggle:
- Form: visual drag-and-drop form builder with an immediate layout preview.
- JSON: direct schema editing, using the raw field keys documented in Field schema reference.
Fields
Fields define what the reviewer sees and what data flows in and out of the task. Each field has:
-
Label: the display name shown to the reviewer.
-
Type: controls validation and input rendering. Available types:
- Text
- Number
- Decimal number
- Date
- Date and time
- Yes or no
- Single select
- Multi-select
- Array
- File
Single select and Multi-select need a configured list of choices, each with a stable id, the value that gets submitted, and the label shown to the reviewer.
-
Direction: how data flows between the process and the reviewer — see Field directions. The JSON view sets this with an explicit
directionkey; the Form view has no equivalent control — direction is derived from the field's lock icon and whether a Binding is set. -
Binding: maps the field to a workflow variable or expression for pre-population, required for Input and InOut fields. Accepts any workflow expression, not just variable references.
-
Variable: shown as an (x) badge next to the field name in the Form view. Automatically derived from the Label for Output and InOut fields only, for example, "Amount Approved" becomes
$vars.<nodeName>.output.amountApproved. Exposes the field's value through the$vars.<nodeName>.output.<varName>access path. Not present on Input fields. -
Required: a static flag, independent of any conditional rule. In the Form view it appears as a Required field toggle inside the field's Field behavior panel, shown only for Output and InOut fields — an Input field is read-only, so requiring it has no meaning.
Multi-column layout
Fields can be arranged side by side in a multi-column grid. Each row supports up to three columns, and field order within the grid can be changed by dragging fields into place.
Field behavior
Fields support conditional display and validation rules, labeled Field behavior in both views. A rule-count badge on the field, shown once at least one rule is configured, opens this panel.
Each rule has:
- An action, such as Show or Hide.
- One or more conditions (a field or variable, a comparison operator, and a value), combined through + Add condition.
Further rules on the same field are created with + Add rule. The Required toggle described above lives in this same panel but is not itself a rule — it's a static flag shown alongside the rules for Output and InOut fields.
Outcomes
Each Quick Form task has one or more outcomes: labeled actions the reviewer can take, such as Approve, Reject, or Submit. Each outcome maps to a sequence flow in the process. After the reviewer selects an outcome and submits, the process routes to the corresponding branch.
Field directions
| Direction | Pre-populated | Editable by reviewer | Written back to process |
|---|---|---|---|
| Input | Yes, from a bound workflow variable or expression | No, read-only | No |
| Output | No (starts empty) | Yes | Yes |
| InOut | Yes, from a bound variable or expression | Yes | Yes, final value replaces the original |
Input surfaces context for the reviewer. Output collects a decision or value the reviewer provides. InOut shows a pre-filled value that the reviewer can correct or confirm.
Setting direction in the Form view
The JSON view sets direction directly. In the Form view, there's no direction field to set — it depends on whether the field is locked and whether it already has a value:
- Case A — Locked, with a value: the field is Input. The reviewer only sees the value; they can't change it.
- Case B — Unlocked, with a value: the field is InOut. The reviewer sees the value and can edit it.
- Case C — Unlocked, no value: the field is Output. The reviewer sees a blank field and provides the value.
Accessing output values
After the reviewer submits the task, output and InOut field values are available downstream at:
$vars.<nodeId>.output.<fieldId>
$vars.<nodeId>.output.<fieldId>
For example, if the node ID is quickForm1 and the field ID is approvalNote, the value is at $vars.quickForm1.output.approvalNote.
Inline debug
Quick Form tasks support inline debug. You can test the full task experience directly from the canvas during a debug session, without publishing the process.
When a debug session reaches a Quick Form node, the task form opens inline in the properties panel, supporting:
- Filling in output and InOut fields as the reviewer would.
- Selecting an outcome to continue the process on the corresponding branch.
- Output values flowing into downstream variables in real time in the variables panel.
Inline debug creates a real Action Center task, the same as it would in a normal run, and submitting the inline form completes that task through Action Center. This lets you validate field bindings, outcome routing, and variable mappings against real task data before publishing.
Inline debug in Agents
When an Agent escalates to a Quick Form task during debug, the same inline form appears. You can respond to the escalation and observe how the agent continues after the human step completes.
No app required
Quick Form tasks do not require an Action App, UiPath App Studio, or any additional deployment step. The schema is packaged and versioned with the process, at no additional licensing cost and with no dependency on the Apps service.
If you need a fully custom interface, such as a branded layout, complex UI logic, or a form shared across multiple processes, use an Action App instead.
Field schema reference
The JSON view exposes each field as an object with these keys:
| JSON key | Form view equivalent |
|---|---|
id | Not shown directly; used in the output access path |
label | The field's name |
type | The Type dropdown |
direction | Not shown directly; derived from Lock + Binding — see Setting direction in the Form view |
binding | The expression box below the field, populated via the expression editor or the Insert variable picker |
variable | The (x) badge next to the field name |
required | The Required field toggle in Field behavior |
rules | Field behavior rules |