# Quick Form

> Pause a workflow and ask a human to review, approve, or fill in a form that you build on the node, then continue with their answer.

**Quick Form** pauses the workflow and assigns a task to a human: a form that you build directly on the node. The human reviews it, fills it in, and selects an outcome, such as **Approve** or **Reject**, and the workflow continues on that outcome's path. It's in the **Human** category of the **Add node** panel.

Use Quick Form for approvals and straightforward data collection. When you need a richer interface, reuse one across workflows, or show data the workflow doesn't already carry, use an [Action App](node-action-app.md) instead. [Add human approval to a workflow](add-human-approval.md) walks through a Quick Form step by step.

## When to use Quick Form vs Decision

Use **Quick Form** when a human needs to review information and respond before the workflow continues. Use [Decision](node-decision.md) when the branch can be resolved automatically from existing data, without a human.

## Configuration

![Quick Form properties panel showing Assignment criteria set to Round Robin with a group search field, a Schema with four fields and Approve/Reject outcomes, and Delivery channels checkboxes for Slack, Microsoft Teams, Email, and Action Center.](https://dev-assets.cms.uipath.com/assets/images/maestro/node-human-configuration-panel-79242253.png)

| Field | Required | Default | Description |
|---|---|---|---|
| **Assignment criteria** | Yes | **Single User** | Controls how the node picks the user who gets the task. Choose between Single User, All users, Round Robin, Workload, or Custom. |
| **Schema** | Yes | Submit outcome | Form structure, including fields the assignee sees or fills in and outcomes they can select. The [Schema](#schema) section describes the full structure. |
| **Delivery Channels** | — | Set by your administrator | Read-only on the node. The available channels come from your administrator's settings and show as disabled checkboxes. The [Delivery channels](#delivery-channels) section has details. |
| **Task title** | No | None | Title shown to the assignee in their task list. |
| **Priority** | No | None | Priority shown in Action Center: **Low**, **Medium**, or **High**. |
| **Labels** | No | None | Comma-separated labels for organizing tasks, for example `finance,approval`. |

## Assignment criteria

Assignment criteria controls which users 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.

| **Criteria** | **Who gets the task** | **Use it when** |
|---|---|---|
| **Single User** | One named user. | A specific individual owns this decision — a named approver, a single reviewer |
| **All users** | Every member of the group at once. The first one to complete it closes the task for everyone. | You care about speed over ownership. Whoever is free picks it up |
| **Workload** | The one group member with the fewest open tasks | You want the queue spread evenly across a team |
| **Round Robin** | Group members in turn, cycling through the membership list | You want each member to take an equal share regardless of how fast they work |
| **Custom** | The 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 users 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 doesn't work.** A test run creates the task where only you can see it, so group members can't open it. The task stays **Unassigned**, and no notifications go out. This is expected. To test group assignment, deploy the workflow and start a run. Single-user assignment works normally in debug.

**Errors you may see:**

| Error | Meaning |
|---|---|
| `NoUsersFoundInLocalGroup` | The selected group has no members. |
| `NoEligibleUsersFoundInGroup` | Every 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.

![Schema editor showing the Amount Requested, Amount Approved, Agent Confidence Score, and Reason fields, with the Amount Approved and Reason fields marked with a Variable badge, and Approve/Reject outcomes.](https://dev-assets.cms.uipath.com/assets/images/maestro/node-human-schema-fields-d07d844b.png)

### Fields

The Schema can also be edited directly as JSON. The full JSON schema reference is in [Quick Form tasks](../../../../action-center/automation-cloud/latest/user-guide/quick-form-tasks.md). In the Form view, each field has these settings:

| Setting | What it does |
|---|---|
| **Label** | The display name shown to the assignee. |
| **Type** | Controls 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. |
| **Binding** | An expression that pre-populates the field, for example `$vars.requestAmt`. Accepts any workflow expression, not only a variable reference. |
| **Editable** | The padlock next to the value. Locked means the assignee can read the value but not change it. |
| **Variable** | Shown 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.

| Binding | Padlock | Direction | Assignee sees | Editable & returned |
|---|---|---|---|---|
| Set | Locked 🔒 | **Input** | The bound value | No |
| Set | Unlocked 🔓 | **In/Out** | The bound value | Yes |
| None | Unlocked 🔓 | **Output** | An empty field | Yes |
| None | Locked 🔒 | *Not valid* | An empty field | No |

### 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. The [Branching on the result](#branching-on-the-result) section shows how.

### Delivery channels

Tasks are delivered to:

- **Action Center**
- **Email**
- **Slack**
- **Microsoft Teams**

:::important
Only an administrator can change the delivery channels, in **Admin settings**. The checkboxes on the node are disabled and show the current settings.
:::

Slack and Microsoft Teams need a connection. [Actionable notifications](../../../../action-center/automation-cloud/latest/user-guide/actionable-notifications.md) covers 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 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.

```
Quick Form
  ├─ Approve → continue processing
  └─ Reject  → notify the requester and terminate
```

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

```javascript
// 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 node.

## Notes

:::note
To test without a real assignee, use **Mock output** to simulate a `status` and `output` response. [Add human approval to a workflow](add-human-approval.md) has 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, use an [Action App](node-action-app.md) instead.

## Next steps

- [Add human approval to a workflow](add-human-approval.md)
- [Action App](node-action-app.md)
- [Decision](node-decision.md)
- [Terminate](node-terminate.md)
- [Quick Form tasks](../../../../action-center/automation-cloud/latest/user-guide/quick-form-tasks.md)