Form-Based Action Steps

Not all the information needed to complete an action is available before the action starts. "Reject an invoice" might need a rejection reason. "Reassign a task" needs to know who to assign it to. "Process a refund" needs the refund amount. This information isn't stored on the record yet — the user needs to provide it as part of the action.

Form-based action steps pause an action chain, collect additional input from the user, and continue with that input available to subsequent steps.

How It Works

A form step in an action chain displays a small form in a modal overlay. The form asks for specific values — whatever the subsequent steps in the chain need. The user fills in the form and clicks a confirm button. The chain resumes with those values available as variables for all following steps.

The pause is seamless from the user's perspective: they initiated an action, provided additional information, and the action completed. From the chain's perspective, it paused at the form step, waited for input, then resumed.

Define the Form Inline

The form displayed by a form step is configured inline within the chain builder. Add the fields you need: text inputs, dropdowns, date pickers, checkboxes. Configure labels and whether fields are required.

This is not a full object form — it's a lightweight input collection specific to the action. It doesn't create or modify records directly; it captures values that subsequent steps use.

Use the Values in Later Steps

Values entered in a form step are available as variables in all subsequent chain steps. A field update step can set a "rejection reason" field to the value the user entered. A notification step can include the user-provided comment in the message body. A conditional branch can check the form value to determine which path to follow.

The chain has access to both the original record's field values and the form-provided values as it executes.

Common Use Cases

• Rejection with reason: Status transition to "Rejected" plus a text field for the reason
• Reassignment: Change the assignee field using a user selected in the form
• Quantity input: Process an action that requires specifying a number (return quantity, adjustment amount)
• Scheduled date: An action that sets a future date requires picking that date
• Comment on transition: A status change that should include a mandatory comment

The UX Result

Actions become richer without becoming more complex for users. A single click initiates the action; the form appears only when additional input is genuinely needed. The user provides the necessary context, and the action completes. The workflow is compact, deliberate, and complete.