Portal Community
Flow Studio

Multi-Page Forms in Workflow Context

Stepper/wizard forms in workflow steps — how each step saves progress, what happens when a user saves and returns later, and how final submission flows back to the workflow.

Atlas Forms Stepper Mode

Atlas Forms supports stepper forms (multi-step wizards) natively. When a stepper form is used in a UserFormNode, the workflow stays suspended for the entire form session — the suspension is not per-step. The Atlas Forms player manages step navigation client-side.

Save Progress (Draft Mode)

Users can save a partially completed form and return later. The Atlas Forms player calls a draft save endpoint between steps:

POST /api/hil-tasks/{taskId}/draft
{
  "currentStep": 2,
  "fieldValues": {
    "step1_name": "Alice Smith",
    "step1_department": "Finance",
    "step2_claimType": "travel"
  }
}

Draft data is stored on the HIL task record. When the user reopens the task, the FormRenderer restores the draft state and positions the form at the last saved step.

Final Submission

Only when the user clicks "Submit" on the final step does the FormRenderer call the resume API:

POST /api/executions/{executionId}/resume
{
  "action": "submit",
  "responseData": {
    "step1_name": "Alice Smith",
    "step1_department": "Finance",
    "step2_claimType": "travel",
    "step3_amount": 450.00,
    "step3_receipts": ["attach-001", "attach-002"]
  }
}

All field values from all steps are collected into a single flat responseData object. This becomes the UserFormNode's full output.

Step Validation

Each step can have its own server-side validation triggered at step navigation (not just final submit). Configure step validators in the Atlas Forms form definition — they are called by the FormRenderer's "Next" button handler.

Field key namespacing: For multi-page forms, use a step prefix convention for field keys (e.g., step1_fieldName, step2_fieldName). This prevents accidental collisions between fields from different steps.
← Validation