> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ingestly.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Retry From node

> Correct the input data of an earlier action and start a linked attempt from that point, without re-running the steps before it.

The **Retry From** node ends a branch by asking for another attempt. Instead of failing a run and leaving someone to start it over by hand, it records the corrections a person (or an upstream check) already made and starts a **linked run** from an earlier action, carrying those corrections in.

A typical shape: extract an invoice, look the purchase order up in Business Central, send the mismatch to a [Review](/nodes/review) so a person can fix the PO number, then Retry From the lookup. The second attempt re-runs the lookup with the corrected number. The extraction is not repeated, and the OCR is not paid for twice.

Retry From is free. The step itself consumes no credits; the linked run bills only the steps it actually executes.

## How a linked attempt works

When the step runs it does not start anything yet. It resolves the corrections, checks them against the target's schema, and records the request on its own step output. The linked run is created when the **source run reaches a terminal state**, so every branch has finished and the run's credits are settled first.

The linked run then:

* Starts at the **target node**, not at the trigger.
* Seeds every step before the target from the source run, so they are never re-executed. In the run detail they read as carried over rather than run again.
* Writes your **input changes** into the seeded output of the node they belong to, so the target reads the corrected values.
* Reserves credits only for the target and what follows it. The completed prefix is not paid for again.

The source run keeps its own result and history. The two are linked: the retry's detail names the run it came from, and the retry limit is counted along that chain.

<Note>
  A **cancelled** run starts no linked attempt. Cancelling is an explicit stop, so the recorded request is simply not acted on.
</Note>

## Configuration

| Field             | Required | Description                                                                                   |
| ----------------- | -------- | --------------------------------------------------------------------------------------------- |
| **Retry From**    | Yes      | The action the linked attempt starts at. Must be an earlier action on this branch             |
| **Input Changes** | No       | Up to 50 fields to replace in the data feeding the target                                     |
| **Retry Limit**   | Yes      | 1 to 10. How many attempts this action may start across the whole linked chain. Defaults to 3 |

### Retry From

Pick any action that already ran before this node on the same branch. Triggers cannot be chosen, and neither can a node inside a [Loop](/nodes/loop) body.

### Input Changes

Each change names an **input field** and the **new value** to put there.

The input field must be a scalar (`string`, `number`, or `boolean`) on the `payload` of a node that feeds the target, written as a plain expression:

```
{{invoice.payload.po_number}}
```

The new value is either a literal or an expression pointing at the corrected data, most often a Review node's output:

```
{{correct_po.payload.po_number}}
```

The two must agree on type. Putting a number expression into a string field, or the text `forty six` into a number field, is reported on the node before you can save.

<Note>
  Only the named fields change. Everything else in the seeded output is carried through byte for byte, so a correction never silently reshapes the rest of the record.
</Note>

### Retry Limit

The limit counts attempts along the linked chain, not per run. With a limit of 3, the third linked attempt still starts and the fourth is refused with `Retry limit reached (3)`. Raise it only if the loop it creates is genuinely bounded, because each attempt spends credits on the steps it re-runs.

## What cannot be repeated

Retry From re-runs everything from the target onward, so it refuses to start when something in that range already reached an external system. If the scope contains a node that **delivered**, or whose delivery outcome is unconfirmed, the step fails rather than sending it twice.

Nodes in the retry scope must be replayable:

| Replayable                                                                                                | Not replayable                                                                 |
| --------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ |
| Extract, Parse, Transform, Merge, Filter, Variable, If, Switch, Reconcile, Prompt, Review, Wait, Download | Business Central and QuickBooks in a write operation, Callback, Email, Forward |
| HTTP in `GET`                                                                                             | HTTP in any other method                                                       |
| Store in `Get`, and the connector lookup operations                                                       | Store in any writing mode                                                      |

If a write sits between your target and the Retry From node, choose a **later** target so the write falls outside the scope.

## Inputs and outputs

**Allowed inputs:** extract, if, switch, HTTP, loop, variable, validation, reconcile, store, prompt, call workflow, review, the connector nodes (Business Central and QuickBooks in any operation, and callback), and the sub-workflow trigger. Maximum one input connection.

**Output:** the node is terminal, so nothing follows it. Its own output records the request:

| Path                             | Description                                         |
| -------------------------------- | --------------------------------------------------- |
| `{{retry.payload.retryRunId}}`   | The linked run's id, or absent in a test or dry run |
| `{{retry.payload.targetNodeId}}` | The node the linked attempt starts at               |
| `{{retry.payload.attempt}}`      | Which attempt along the chain this one is           |
| `{{retry.payload.inputChanges}}` | Each change, with its previous and new value        |

(Replace `retry` with your node's actual name.)

## Testing a workflow with a Retry From

**No linked run is created in a test.** In a [test step](/workflows/editor#test-step) or a [dry run](/workflows/editor#dry-run), the node resolves and validates everything (so a bad input field still fails there) and records the request, but nothing is started. Only a [live run](/workflows/editor#live-run) creates the linked attempt.

## Limits

* **Root workflows only.** The node refuses to run inside a sub-workflow, a loop iteration, or any child run.
* One Retry From per workflow. A second one is reported on save, so two branches can never race to decide which correction wins.
* Maximum one input connection, and the node cannot go inside a Loop body.
* A linked chain is capped at 100 runs regardless of the retry limit.

## Errors

* **Retry From is only available in a root workflow**: the node ran inside a sub-workflow, a loop iteration, or another child run.
* **Choose an earlier action in the same root workflow to retry**: the target is empty, is a trigger, sits inside a container, or is no longer upstream of this node.
* **Retry limit must be between 1 and 10**: the Retry Limit field is empty or out of range.
* **Choose up to 50 input changes**: more than 50 changes are configured.
* **Input fields must belong to data feeding the selected target node**: an input field names a node that does not feed the target, such as one downstream of it.
* **Select a scalar input field for 'X'**: the field resolves to an object or an array.
* **Input field 'X' does not exist in its schema**: the field is not in the source node's declared schema.
* **The new value for 'X' must have the same type as the input field**: the value's type does not match the field's.
* **Retry limit reached (N). Review the input data before starting another run**: the chain has used its attempts.
* **Retry From cannot repeat a delivery that succeeded or has an unconfirmed outcome**: a delivery inside the retry scope already went out.
* **Retry From cannot automatically repeat 'X', which may have written external data. Retry from a later action**: a node in the scope is not replayable.
* **Only one Retry From action is allowed**: the workflow contains more than one Retry From node; the message names them.

## Related

<CardGroup cols={2}>
  <Card title="Review action" icon="user-check" href="/nodes/review">
    Collect the corrections a retry carries in
  </Card>

  <Card title="Reconcile action" icon="scale-balanced" href="/nodes/reconcile">
    Find the mismatch worth retrying
  </Card>

  <Card title="Monitoring runs" icon="chart-line" href="/runs/monitoring">
    Follow a linked attempt back to the run it came from
  </Card>

  <Card title="Expressions and filters" icon="code" href="/guides/expressions">
    Write the value a corrected field receives
  </Card>
</CardGroup>
