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.