Requests

Handle the points in running operational processes where a person must decide, supply missing information or take responsibility for an exception.

Requests are where a running Workflow asks a person for a specific decision or missing information before it can continue.

Think of the Request as a deliberate boundary in the operational process: the automation has done what it can safely do, and now a person with the right context or authority needs to act.

A live Request Inbox with an open high-priority decision, filters and request context.

Examples include:

• approve an invoice exception;

• confirm which customer an order belongs to;

• provide a missing reference number;

• choose between two possible products;

• supply information that is not available in the connected systems.

What happens when a Workflow needs you

A Workflow can pause at a configured Request Decision or Request Input step. The Request shows what is needed and the context configured for that process.

A Workflow app session waiting for a person to respond to a decision Request.

The exact wording, choices, form fields, assignment and point in the process are specific to the Workflow and organisation. Live Requests are assigned to users directly or by role. Assigned users can respond normally. For Decision Requests, Builders and higher-access users who are not assigned can respond on behalf of an assignee; the UI makes that explicit and records the response that way. Request Input forms do not currently offer that on-behalf path, so unassigned users see them read-only.

An opened Decision Request showing response controls and the on-behalf-of banner for an unassigned builder.

Once the Request is completed, the underlying execution can continue using the response.

Agent questions inside an Agent session are separate. An Agent asking you something in conversation does not automatically create an item in Requests. See Requests, exceptions and human attention for the conceptual distinction.

What to do with a Request

When you open one:

1. understand what the automated work has already established;

2. identify exactly what decision or information is still missing;

3. review the evidence provided;

4. respond with the requested decision or input;

5. submit it so the Workflow can continue.

Verify Request fields against the source document

When a Request form is shown beside a searchable PDF, supported document-derived fields can be traced back to the evidence they came from. Hover the field or move keyboard focus to it to highlight matching occurrences in the PDF. If the first match is on another page, the viewer scrolls to it.

An approval Request opened beside its source order document so the operator can review the evidence before deciding.

A completed Request showing the Total Due field and its matching value highlighted in the adjacent source PDF.

This works for plain text and numeric fields. Select/enum and file fields are excluded, as are formatted values such as dates and times, records, users, email addresses and URIs.

Matching is deliberately tolerant of common formatting differences such as currency symbols, thousands separators, decimal comma versus decimal point and extra spacing. If the same value appears more than once, matching occurrences are highlighted together.

If a value accepted from the document cannot be found in the PDF text, the field gets a soft check note. It does not block the Request from being submitted. Fields that a person entered or corrected themselves do not get that missing-match note.

Only searchable PDF text can be matched. Image-only scanned PDFs cannot be highlighted this way. The current search covers the first 100 pages of the PDF and highlights up to 50 matches for one value.

The same shared PDF-highlighting component is reused in some adjacent record and Workflow-app previews. The operator capability documented here is the Request verification step: checking a requested value against its source before responding.

Find and manage Requests

The Request Inbox can be filtered by the operational context you need, including assignee, Workflow, record, status, decision, your own status and date range. You can also hide completed or responded Requests, show archived Requests, and use Project-specific metric filters where they are configured.

Decision filters distinguish work that is still waiting from outcomes that have already been recorded. Awaiting decision matches Requests that still need an answer. A named decision outcome matches Requests where that answer has already been submitted. Because an outcome filter already selects answered Requests, Hide completed is not useful alongside named outcomes and may be unavailable. To build a view of open exceptions, use Awaiting decision and narrow the view with title, assignee, Workflow or other context filters.

Archived Requests are hidden from the normal Inbox until you choose to show them. Archiving changes whether a Request is visible in that working view; it does not itself change the Request's underlying response or execution status. This distinction matters when you compare Inbox counts with historical or operational reporting.

The Request Inbox filter menu with assignment, Workflow, record, status and response-state filters.

A Request's action menu can expose controls such as Edit Assignee, View Session and Archive Request. Re-open is deliberately more restricted: it appears on completed Requests for assignees rather than as a general admin action.

The action menu for a Request, including Edit Assignee, View Session and Archive Request.

Reopen and SLA behaviour

A completed Request can be reopened in supported cases to replay execution from that handoff. Re-open creates a new Request from the completed one; pending Requests in the same session that are superseded by that replay are marked superseded. Only an eligible completed Request can be reopened, and the control is shown to assignees rather than to unassigned administrators.

A Request can also carry priority and an SLA deadline. Today the deadline is informational: Lleverage does not automatically escalate a Request or move it into at-risk or overdue states. If your operation needs escalation, that behaviour must be configured explicitly rather than inferred from the SLA field.

Retries are separate from human handoffs. Retrying execution does not intentionally re-issue the Request as a new piece of work.

Repeated Requests are useful evidence

If the same question repeatedly reaches a person, it may expose missing data, an undocumented rule, weak system access or a decision that could be handled more consistently.

That does not mean every Request should disappear. Some decisions genuinely belong with people. But recurring handoffs are useful input to Build and improve.

Related documentation

• Understand how Requests fit into the execution model → Humans, Agent and Workflows

• Configure a Workflow handoff → Human handoffs

• Investigate repeated exceptions → Monitoring