Retrigger & recovery

When a request gets stuck part-way through a workflow — usually because an integration call failed or returned unexpected data — you don't have to abandon it. Retrigger lets an admin re-run the affected step (and optionally the rest of the flow) from the request's Progress Path, so the request can continue from where it stopped.

This page explains when a request becomes Blocked, the difference between retriggering a single step and retriggering through to completion, and how to provide custom inputs to get a blocked step past a bad response.

📘

Where you'll see it

Open Workflows Studio › Reports, open the request you want to fix, and go to its Progress Path. Each step (node) shows its status; blocked or failed steps expose the retrigger actions described below. Retriggering requires the Take action report permission (RBAC).

📒

Key terms

  • Blocked — a request the engine could not advance automatically (internally stalled). It stops and waits for an admin to intervene.
  • Progress Path — the per-step timeline of a request in Reports, where each step's status and actions appear.

How a request becomes Blocked

Before a request is marked Blocked, the platform tries to recover on its own:

  • Action node retriesAction nodes can be configured to automatically retry a failed integration call a set number of times, at a set interval (see Action node › Re-try). Retries use an idempotency key so the same call isn't accidentally processed twice by the external system.
  • Automatic engine recovery — if a step stalls (for example, a worker restarts mid-execution), the engine re-attempts it automatically, up to an internal limit of 5 attempts.

If automatic recovery is exhausted — or the step hits an error it can't recover from — the request status becomes Blocked and waits for a manual retrigger.

Retrigger options

From a blocked or failed step on the Progress Path, an admin has three options:

Re-trigger

Re-runs just the selected step. Use this to re-attempt a transient failure (for example, the external system was briefly unavailable).

The confirmation reads: "Re-triggering this step will only re-execute the selected step. This action may affect the overall status of the workflow." You can tick Allow the workflow status to be updated so the request's overall status is recalculated once the step succeeds.

Re-trigger the step and flow

Re-runs the step and then lets the engine continue through the remaining steps to a terminal state. Use this when you want the whole request to finish, not just re-run one step.

The confirmation reads: "Re-triggering this step will also execute the remaining flow. The request status will change to 'In Progress' until the flow is completed."

Provide inputs

For Action and Function steps, you can supply the step's result manually instead of re-calling the integration — useful when the external system keeps returning bad data or you need to unblock a request with a known-good value.

This opens the Provide input panel ("You can edit and provide inputs on the blocked node") with a Request body editor. Enter the correct JSON payload and click Submit; the engine uses your input as that step's result and continues. Custom inputs are only accepted while the step is Blocked.

Retrigger a blocked request

  1. Go to Workflows Studio › Reports and open the request (item).

  2. Open its Progress Path and locate the Blocked or failed step.

  3. Choose an action on that step:

    • Re-trigger (this step only) — optionally enable Allow the workflow status to be updated, then confirm.
    • Re-trigger step and flow — to continue through the remaining steps; confirm.
    • Provide input — edit the Request body JSON and Submit to supply the step's result.
  4. The step re-executes. Retriggered steps are tagged on the timeline with who retriggered them and when, so the action is auditable.

⚠️

Things to know

  • Permissions — retriggering needs the Take action report permission.
  • No infinite auto-recovery — automatic recovery stops after 5 attempts to avoid loops; a persistently failing step must be fixed in the workflow builder (or the request withdrawn) rather than retriggered repeatedly.
  • Custom inputs are for blocked steps only — and apply to Action/Function steps, where you supply the result the integration would have returned.
  • If a request is stuck but no step shows as actionable (for example, it stopped right after a Sync Block), that's a path-propagation edge case handled by support tooling rather than the standard retrigger flow — raise it with your Leena AI contact.