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

# States and recovery

> Find ContentFlow processing failures by trace or batch, inspect their logs, and choose a full rerun or retry from the failed step.

## Prerequisites

You need `states.view` to investigate states and logs, and `states.retry` to request a retry. Access to the workflow editor is also needed to inspect its diagram.

## Find the item

Open **States**, set the date range, and choose **Search**. Use the column filters for trace ID, status, initial workflow, or batch name. Open the matching state to inspect its current workflow and trace logs.

| Status             | How to interpret it                                                     |
| ------------------ | ----------------------------------------------------------------------- |
| **Pending**        | Waiting to be processed                                                 |
| **Started**        | Processing has started; do not treat it as a completed import           |
| **Completed**      | The run completed; verify the expected destination outcome where needed |
| **Failed**         | Processing failed and needs investigation                               |
| **ScheduledRetry** | A retry has been requested; it has not yet completed                    |

The trace view includes logs and can open the relevant workflow **on the diagram**. Use it to identify the failed step and its input context before changing configuration or requesting another execution.

## Fix the cause first

Check the error against the step's input, mapper, global variables, and target-system response. Typical causes include missing metadata, an unexpected file format, unavailable credentials, or a receiving service rejecting the operation.

Keep the trace ID, batch name, workflow, time, and error when escalating. Include only the metadata needed to reproduce the failure.

## Choose a recovery action

The **Rerun** page accepts trace IDs and can load failed states by batch name. Only failed states are accepted for retry.

| Action                   | Use when                                                                                  |
| ------------------------ | ----------------------------------------------------------------------------------------- |
| **Full rerun**           | The item needs the pipeline from the beginning, and repeating earlier steps is acceptable |
| **Run from failed step** | Earlier steps succeeded and the recorded failed-step context is suitable for resuming     |

When saved failed-step information exists, the second option supplies that step and its recorded data to the retry. Without that information, do not assume earlier steps will be skipped.

<Warning>
  Reruns can repeat uploads, messages, or other external changes. Check what succeeded before the failure, and test one trace before rerunning a whole batch. A retry request being accepted means it was scheduled, not that processing succeeded.
</Warning>

Executions that recorded a published version are normally retried against that version. If recovery depends on changed workflow logic, inspect the recorded version and confirm the recovery path before repeating the request; a newly published definition may not be used by the retry.

After recovery, return to **States**, check for a completed result, inspect the trace, and verify that the expected destination record exists without unintended duplicates.

## Where to read next

<Card title="API clients and service accounts" icon="plug" href="/integrations/api-clients" horizontal>
  Create a dedicated machine identity, grant its group access, rotate its secret, and disable an integration.
</Card>