> 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. ## 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. ![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. 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.](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) ## 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](/build-and-improve/overview.md). ## Where to go next * 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` 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 optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.