> For the complete documentation index, see [llms.txt](https://docs.lleverage.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lleverage.ai/run-operations/request-inbox.md). # 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.](https://3370306531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlgSglJDQZxDZdn20CUcl%2Fuploads%2F1ldfl1Ahzvt7fZcQfdy2%2Frequests.png?alt=media) 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.](https://3370306531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlgSglJDQZxDZdn20CUcl%2Fuploads%2FzG2ElVEKMgUfCGV2mQa9%2Frequest-human-in-loop.png?alt=media) 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.](https://3370306531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlgSglJDQZxDZdn20CUcl%2Fuploads%2F16DEJjFN6bNUYG2ZX0bg%2Frequest-response-controls.png?alt=media) Once the Request is completed, the underlying execution can continue using the response. Agent questions inside an [Agent](/run-operations/agent.md) 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. ## Comments while a Workflow runs The comments panel brings together notes on the current Request and other Requests in the same Workflow run. Notes from earlier handoffs remain visible to later reviewers. If an invoice is associated with the run, its notes can appear here too. Comments provide context but do not answer a Request. The assigned person must still submit the requested decision or information. The panel currently shows up to the first 100 notes in the combined history; newer notes may not appear on long-running work. ## 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.](https://3370306531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlgSglJDQZxDZdn20CUcl%2Fuploads%2FzpzZhKYqGm4lB1bofNO3%2Frequests-inbox-approval.png?alt=media) ![A completed Request showing the Total Due field and its matching value highlighted in the adjacent source PDF.](https://3370306531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlgSglJDQZxDZdn20CUcl%2Fuploads%2FowISWQHcNDkWJssLidbk%2Frequest-field-source-highlight-total-due.png?alt=media) 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. An archived pending Request can still be answered. An archived failed Request cannot be retried until it is unarchived. 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.](https://3370306531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlgSglJDQZxDZdn20CUcl%2Fuploads%2Fh85OdcHDxuZxJ37qHyCF%2Frequest-filter-menu.png?alt=media) 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.](https://3370306531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlgSglJDQZxDZdn20CUcl%2Fuploads%2Fk3BeqLai2pHyltbkxGxn%2Frequest-actions-menu.png?alt=media) ## Keep the Inbox focused on your work Each saved view keeps its own filter edits for you in this browser. Switching views or opening another tab does not discard those edits. **Reset to view**, or selecting the active view tab again, restores the saved filters. Saving or deleting a view yourself clears your local edits for it. When you open Requests without an explicit view, it returns to the last view used in that browser tab, falling back to the default if that view is no longer available. Links and pins that name a view still open that view. After you answer, the Inbox continues watching for the next step assigned to you in the same case. When creating or editing a view, use the eye controls to choose which filters appear in its Filter menu. This choice belongs to the shared view. A filter already applied to the view stays visible as a chip and remains editable even if hidden from the menu. On desktop, **Hide requests list** gives the open Request the full detail panel. **Show requests list** brings the list back; dragging the divider still works. On mobile, use the back arrow to return to the list. ### Reassign one step or the remaining work For a Request Input step in a run, **Edit Assignee** offers **Reassign task** for that step only, or **Reassign person** for that person's remaining work in the run. The latter moves their open input steps and hands their later input steps to the replacement. Approval steps keep their configured assignees, and steps assigned to other people stay with them. Bulk reassign and API/MCP reassignment still affect only the selected step. If the replacement loses Project access before a later step is created, that step falls back to its configured assignee. ## Reopen and SLA behaviour A completed Request can be reopened in supported cases when **Allow revisiting** was enabled for the step in the Workflow version that ran. The earlier response stays in history; later steps run again and earlier side effects are not undone. 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](/build-and-improve/overview.md). ## Related documentation * Understand how Requests fit into the execution model → Humans, Agent and Workflows * Configure a Workflow handoff → [Human handoffs](/build-and-improve/automate/human-handoffs.md) * Investigate repeated exceptions → [Monitoring](/build-and-improve/monitoring.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.lleverage.ai/run-operations/request-inbox.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.