> 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/build-and-improve/automate/human-handoffs/request-input-page.md). # Request Input Pause a Workflow and collect structured information from an assigned person before execution continues. Request Input pauses a running Workflow to collect information that is required before the process can safely continue. Use it for missing data, human verification, a structured correction, supporting information or other input that cannot be obtained reliably from the systems already available to the Workflow. ## What happens in a live Workflow When execution reaches Request Input, Lleverage: 1. evaluates the configured form 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. validates and records the submitted response; 6. resumes from the saved point with the submitted data available downstream. The output includes the submitted values, provenance describing how form values were provided, and `resolvedBy` information for the person who completed the Request. ## Configure only the information the process needs Keep the form specific to the operational gap. A good Request Input tells the assignee: * what information is missing; * why it is needed; * what evidence they should inspect; * which fields are required; * what will happen after submission. The exact fields and form structure are defined by the Workflow. They are not a universal Request schema across Lleverage. ### Edit table line items directly When an Item List is shown as a **Table** in a Request Input 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. ![Inline editing a line-item cell in a Request Input form.](https://3370306531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlgSglJDQZxDZdn20CUcl%2Fuploads%2FD1O25jSe8EkiGQ8GeEQK%2Flle-12992-inline-edit-cropped.png?alt=media) 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 in a live Workflow. The current builder node exposes assignment to specific users, and only an authorised assignee can complete the Request. Do not describe role-based assignment as a visible builder capability today, even though the underlying Request data model can represent role assignments. ## Reopening input A completed Request can be reopened in supported cases to replay execution from that handoff. Reopen the latest completed Request in the chain; earlier superseded Requests cannot be independently reopened. ## Priority and SLA Priority and an SLA deadline can be stored with the Request. The deadline does not currently trigger automatic escalation or at-risk/overdue transitions. Treat it as Request metadata unless your Workflow explicitly implements escalation behaviour. ## Builder tests behave differently In a builder test, the input form is handled inline and no real Request Inbox row is created. Assignment and Request authorisation are not enforced in test mode, and no Workflow Session is created for this Request flow. That makes test mode useful for checking the form and downstream data path, but it does not prove that live assignment and Request handling are correct. For the operator experience, see **Run operations → Requests**. --- # 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/build-and-improve/automate/human-handoffs/request-input-page.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.