Troubleshooting and support

Use the product evidence available for an issue, separate operator, builder and administration problems, and escalate with enough context to investigate.

Start by identifying which layer of the operation is wrong. A useful investigation is usually faster than retrying or changing configuration at random.

If operational work looks wrong

For an Agent session, first inspect the session itself: the request, context used, tool activity and resulting output.

For a published Workflow app, confirm what was submitted and whether the underlying Workflow execution completed or produced a Request.

For a Request, review the evidence and question presented by that specific Workflow before responding. Request wording and available decisions are process-specific.

If an Agent or Workflow execution failed

Builders should use Monitoring to inspect the run and trace. Look for the failing action, relevant input/output and whether the failure is isolated or recurring.

A Workflow test is a real execution and can have real external side effects. Do not repeatedly test a failing write path against production data merely to collect more evidence.

If a configured action has retry enabled, that is specific to that action. Lleverage does not provide a general fallback mechanism that automatically makes every failed Workflow safe to retry.

If a connected system is involved

Check both sides of the integration:

• the relevant Connection exists in the intended Project;

• the external identity still has the required permission;

• any delegated/shared-resource permission is actually enabled for the connected identity;

• the requested resource belongs to the expected tenant/account;

• no credential or token has been copied into ordinary project content as a workaround.

See Data, connections and credentials for the authority model.

If access or configuration looks wrong

Use Control for current project configuration and membership. Product roles do not replace the organisation's own decision about who should own, operate or approve the underlying process.

If the service itself may be unavailable

Check Lleverage System Health before treating an application-wide problem as a Workflow-specific failure.

Escalating an issue

When contacting Lleverage, include the smallest set of evidence that lets someone investigate without exposing secrets:

• organisation and Project;

• approximate time of the issue;

• session, run or Workflow identifier where available;

• what you expected and what happened instead;

• the relevant Monitoring trace or screenshot;

• whether the issue is reproducible and whether retrying would create external side effects.

Do not paste API keys, passwords, bearer tokens or other secret values into the report.

Formal incident-response, retention or security-evidence requirements should be verified through current support or assurance material rather than inferred from generic documentation.