Forms

A form is the structured screen a person fills in to complete a user task. Instead of a fixed pair of buttons, a user task shows the form you designed for it — the fields to capture, the validation to enforce, and the actions the person can take.

What a form is made of

• Fields — typed inputs. Text (and textarea, email, URL), number or integer, yes/no, a single choice (dropdown or radio) or several (multi-select or checkboxes), dates and date ranges, file uploads, and repeating rows — an array of sub-fields, for line items and the like.
• Validation — per field: required, min/max length or value, a pattern, a min/max number of items, accepted file types and size. The form won’t submit until every rule is satisfied.
• Actions — the buttons at the bottom. Each has a label and a style (primary / secondary / destructive), can ask for confirmation, and can either validate the form first or skip it (a “Save draft” that doesn’t).
• Sections — fields grouped into labelled sections, so a long form stays readable.

Dynamic forms

Forms aren’t static. A field can:

• Show only when it’s relevant — reveal “Reason for rejection” only when the outcome is Reject.
• Become required conditionally — make “Justification” required only for flagged cases.
• Compute its value, or validate itself, with an expression — written in FEEL, a small, readable business-rules language (for example, the approved amount can’t exceed the policy limit).

Repeating sections can let the person add and remove rows (bounded by a min and max), so they can enter as many line items as the case needs.

FEEL

FEEL — Friendly Enough Expression Language — is the same expression language behind Decisions. In a form it’s optional: plain fields and validation cover most cases; reach for FEEL when a field’s visibility, value, or validity depends on the others.

Where forms live, and how a task uses them

Forms are reusable building blocks. You design a form once in the Forms library (at the organization level) and version it like anything else; a process then binds a form to a user task. When the task reaches someone’s inbox, the platform renders the form alongside the task’s data — either as a separate card (with the task data read-only beside it) or unified, with the fields inline-editable inside the task-data sections.

Because the actions come from the form, “approve / reject” isn’t hardwired: a task offers whatever set of decisions its form defines.

Next

Build a formDesign a form with fields, validation, and dynamic rows.

Use a form in a taskBind a form to a user task so people submit structured data.

Tasks and human-in-the-loopHow a task renders and completes a form.