Request a decision

Pause a Workflow and ask an assigned person to make a defined decision before execution continues.

Request Decision creates a deliberate decision point in a running Workflow.

Use it when the Workflow has enough context to present a bounded choice, but a person should retain the authority or judgement to choose the outcome.

What happens in a live Workflow

When execution reaches Request Decision, Lleverage:

1. evaluates the configured title, description, options and supporting context;

2. creates a Pending Request for the assigned user;

3. stores a resume snapshot for the Workflow;

4. pauses the run;

5. resumes from that snapshot after an authorised assignee completes the Request.

The selected option is then available to downstream Workflow logic. The output includes the selected value and label, its index, and a boolean output for each configured button.

Configure the decision around the work

A useful decision Request should make clear:

• what is being decided;

• the evidence the assignee needs;

• the available choices;

• what authority or judgement the person is exercising;

• the priority and any relevant deadline.

Attachments and related operational context can be included where the Workflow provides them. Keep the options bounded enough that the next execution path is unambiguous.

Edit table line items directly

When an Item List is shown as a Table in a Request Decision form, inline editing is on by default unless the builder explicitly disables it. The assignee can click a cell to edit that value without opening the full row editor. Enter or clicking away saves the change, Escape discards it, and leaving the value unchanged does not write an update.

Checkboxes save when clicked, while file, record and user fields keep their normal pickers. The row menu can also be used to edit the full row, move it, duplicate it or add another row where the form allows it.

Assignment

Assignment is mandatory for live Requests. The current builder node exposes assignment to specific users. Only an authorised assignee can complete the Request.

Do not document role-based assignment as a current builder capability: the underlying data model can represent roles, but the visible Request Decision configuration currently exposes user assignment.

Reopening a completed decision

A completed Request can be reopened in supported cases, which replays execution from that handoff. Only the latest completed Request in a reopen chain can be reopened; a superseded ancestor cannot be reopened independently.

Reopening is for revisiting the operational decision, not for editing the old execution history in place.

Priority and SLA

Priority and an SLA deadline can be recorded on the Request. The deadline is currently informational: Lleverage does not automatically escalate the Request or mark it at risk/overdue. If the process requires escalation, model that explicitly.

Builder tests behave differently

In a builder test, Request Decision is handled inline rather than creating a real Request Inbox row. Assignment and Request authorisation are not enforced in test mode. Test the live assignment path deliberately before relying on it in production.

For the operator experience, see Run operations → Requests.