All resources
Design4 min read

Designing task forms

Build the forms people fill in during a process: 22 component types, validation, conditional fields, versions and translations.

In short

  • 01

    Drag components onto a 12-column grid — no code.

  • 02

    Show, hide and validate fields with FEEL expressions.

  • 03

    A running task keeps the exact form version it started with.

When a process reaches a user task, someone has to enter or review data. The form designer in Studio is where you build what they see.

A form's life

Draft
Validated
Published
Deployed
Retired

A form can only be edited while it is a draft. Once deployed, it can be attached to user tasks. To change a published form, restore a version as a new draft.

What you can build

CapabilityHow it works
Layout22 component types on a 12-column grid, with groups and repeating lists
ValidationRequired, minimum and maximum length or value, pattern, email / phone / URL, or a custom FEEL rule
Conditional fieldsHide a field, or make it read-only or disabled, with a FEEL expression
OptionsFixed lists, a process variable, or a FEEL expression
TranslationsOne set of labels per language; missing translations fall back to the original label
VersionsFull change history, a component-by-component diff, and restore

Try it before you publish

The playground runs a form against sample data. It shows which fields end up hidden or read-only, which validation rules fail, and which values would actually be written back to the process.

Validating and publishing a form also runs accessibility checks — for example a field without a label. Findings are recorded in the form's audit trail.

Forms and running tasks

A task pins the form version it first opened with. Editing the form later never changes what an already-open task shows or validates against.

Current limits: the table component and file upload cannot yet be submitted when completing a task.

See it on your own process

Book a walkthrough with the Orkovia team.

Request a Demo