> 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/understand-lleverage/readme/requests-exceptions-and-human-attention.md).

# Requests and exceptions

Understand what Requests are, what operators can expect, and why their exact setup differs by organisation and workflow.

Operational work does not always have a clean straight-through path. Information can be missing, a price can look wrong, an unusual supplier can appear, or a decision may require authority that the automation does not have.

In Lleverage, a Workflow can create a **Request** when it needs a person to provide input or make a decision before the work continues.

## Request types

If a Request is assigned to you, it appears in the project's Requests area. Depending on how the Workflow has been configured, you may be asked to:

* choose between one or more decisions;
* provide missing information through a form;
* review context produced earlier in the Workflow;
* provide information that the Workflow will use when it resumes.

When the assigned person resolves the Request, the Workflow continues from that point.

## Workflow configuration

There is no single universal Request design.

The title, context, available decisions, required fields, assignment and the point in the process where the Request appears are configured as part of the Workflow. Two organisations may handle the same kind of operational decision differently because their policies, responsibilities and risk boundaries differ.

The documentation therefore explains the common Lleverage behavior. The exact decisions and forms you see in your project depend on how your organisation has configured the work.

## Request state

A Request usually means the running process has reached a configured human boundary. It does not necessarily mean something has failed.

Examples:

* a purchase above a threshold requires approval;
* a product cannot be matched confidently and needs confirmation;
* an order is missing information that only the commercial team can provide;
* an exception does not fit the normal automated path.

Routine work can continue in the background while configured human decisions are surfaced as Requests.

## Repeated exceptions

If the same Request keeps appearing for the same reason, that can be a useful signal for builders and process owners. It may mean a rule, Skill, Workflow step, maintained data source or upstream process should be improved.

Not every exception should be automated away. The useful question is whether the repeated human step represents real judgement, or work the system could safely resolve with better configuration or information.


---

# 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/understand-lleverage/readme/requests-exceptions-and-human-attention.md?ask=<question>&goal=<user_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.