Skip to main content
When an integration 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, 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.
ActionWhat it doesUse when
RetryReplays a single failed action without re-pulling from the sourceA record failed for a transient reason that you have since resolved
ResyncRe-pulls data from the source over a broader scopeYou fixed a mapping or configuration issue, or records are missing
ArchiveChanges a record’s status to inactive while keeping its historyA 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. For connector-specific error handling, see the page for your integration in the integrations catalog.
Last modified on June 29, 2026