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

# Retry, Resync, and Archive: Managing Integration Syncs

> Understand the difference between retry, resync, and archive when running DualEntry integrations, and when to use each to resolve sync issues.

When an [integration](./index) runs, DualEntry reports each run to the integration's Sync History so you can see what synced and what failed. Three actions come up repeatedly when you work through sync issues: retry, resync, and archive. They are not interchangeable. This page explains what each one does and when to reach for it.

## Retry

Retry re-attempts a single failed record or action. Use it for transient failures, such as a network blip or a temporarily [locked period](../core-financials/general-ledger/period-locking), where the underlying data is correct and the operation simply needs to run again. Retry does not re-pull data from the source system; it replays the action DualEntry already has.

Failed records appear in the integration's Sync History with the reason they failed. Once you have resolved the cause (for example, unlocking the period or fixing a missing account mapping), retry the affected record to post it. If the same record fails again after retry, the problem is usually a configuration issue rather than a transient one, and a resync is the better next step.

## Resync

Resync re-runs the sync over a broader scope and re-pulls data from the source system. Use it after you fix a mapping or configuration problem so DualEntry picks up the corrected data, rather than replaying the stale version it failed on. DualEntry supports three resync modes:

* **Manual resync (Sync Now)** triggers an immediate sync from the last successful sync point.
* **Date range resync** re-pulls records within a specific window, which is useful when you have corrected data for a known period.
* **Full re-import** clears and re-imports all data in scope. Use this only when necessary, because it is the heaviest operation.

Because resync re-pulls from the source, it is the right tool when records are missing, when a mapping changed, or when a category of transactions stopped landing in DualEntry. Resync respects the integration's cut-off date and deduplicates on each record's external ID, so a resync does not create duplicates of records that already posted.

## Archive

Archive is a record status change, not a sync action. Archiving marks a record (such as a fixed asset, contract, or paper check) inactive so it no longer appears in active list views, while preserving its history and audit trail. Archived records typically move to a separate Archived tab in list views and can be restored where the record type supports it.

Reach for archive when a record should be retired from day-to-day work but kept for historical reference. It does not re-run a sync or re-attempt a failed action, so use retry or resync, not archive, to resolve a sync failure.

## Choosing between them

The table below summarizes when to use each action.

| Action  | What it does                                                      | Use when                                                            |
| ------- | ----------------------------------------------------------------- | ------------------------------------------------------------------- |
| Retry   | Replays a single failed action without re-pulling from the source | A record failed for a transient reason that you have since resolved |
| Resync  | Re-pulls data from the source over a broader scope                | You fixed a mapping or configuration issue, or records are missing  |
| Archive | Changes a record's status to inactive while keeping its history   | A record should be retired from active views but kept for reference |

For how integrations report sync runs and surface errors, and for the engineering detail behind resync modes, see [Building a Custom Integration](/developers/guides/building-a-custom-integration). For connector-specific error handling, see the page for your integration in the [integrations catalog](./index).