Skip to content

Build user forms and workflow commands

26R1 reference · Documentation-based tutorial draft · Not executed in IFS

Workflow learning center · Explore this pattern interactively

A User Task collects input from the current user. It does not route an approval task to a different person or role.

User forms are invoked through a projection reaction using User Interaction / After, or through a compatible workflow command. They cannot be used in asynchronous processing, including a form reached indirectly through a cascading workflow.

  1. Create a new development workflow and add a Start, User Task, and End.
  2. In the User Task’s Forms tab add a text field with a unique ID such as handoverNote.
  3. Configure localized labels, the expected type, and any supported default.
  4. Inspect the workflow and enter a short fictional note.
  5. Add an IFS API Task only after confirming which writable attribute should receive the note.
  6. Map the form variable explicitly to the API parameter and test the real business role.

Form IDs cannot contain spaces and must be distinct within a form, including case-only differences. They become variable names; avoid overwriting unrelated inputs.

Static enumeration choices are supported, but IFS-managed enums and LOV controls are not interchangeable with them. Long text also has special restrictions: the user-form considerations warn about attributes at or above 2,000 characters before a User Task. Verify long-text scenarios separately.

Work before a form is committed before the form interaction. Submission continues in a new transaction. Canceling the form or failing afterward does not undo changes already committed before it.

Put a deliberate test in your matrix: change something before the form, cancel, and inspect the persisted outcome in development. Never describe the whole flow as all-or-nothing unless its boundaries support that claim.

Users should finish forms with OK or Cancel. Abandoned forms can leave incomplete workflow instances requiring operational attention.

In Page Designer, use the supported ExecuteWorkflow custom-command type on the intended page/data source. Choose a deployed workflow that passes workflow-command validation. Map the available record context and publish in the intended configuration context.

Command compatibility is checked during publication and when deployments change. A deployed workflow can still be ineligible. For example, command validation excludes asynchronous transitions and a combination of User Tasks with validation terminate events.

Test record selection, no selection, denied access, successful completion, cancellation, and page refresh. The form’s Refresh the Page setting can affect what the user sees after subsequent API changes.

Commands are normally single-record operations. The documented Deferred Enable workaround can execute once per selected row; treat that as repeated executions with corresponding load and side effects, not as one atomic bulk transaction.