Resolve errors – automatically or manually

Anitha Abraham

Updated July 14, 2026 16:14

You can manage errors in flows by configuring automatic recovery or resolve settings, if they're disabled, or by manually retrying and resolving specific records. This article covers both automated and manual options to clear your error queue.

If you want to manually resolve errors, this article focuses on troubleshooting errors from details available on the Errors page.

When you successfully retry/resolve errors, the error count shows a decrease on the step in flow builder & completed flows in the dashboards. Similarly, the error resolution count shows an increase in the User-resolved or Auto-resolved columns in the dashboard.

Note

In the Celigo Community – Connective, you're welcome to:

share your solution if any error you resolve will help other platform users too
ask a question if you’re stuck with an issue (or raise a Support ticket to resolve the issue)

Prerequisites

Permissions: You must have Administer or Manage permissions to modify connection settings, retry errors, or resolve records. Users with Monitor permissions can typically only view error details, but if the Admin has granted permission, then they can also edit the retry data.
Data retention: Error retry data is available for the most recent 20,000 errors per flow step or according to your specific data retention plan.
Time limits: You can retry open errors if the record timestamp is within the default last 30 days or upto 180 days based on your subscription. For more information, see retain your log and error data..

Automatically resolve errors

The Celigo platform includes features that automatically resolve errors to reduce manual intervention and troubleshooting time. These features are turned on, by default, for new flows and connections.

Connection setting: Auto-recover rate limit errors

For connections encountering API rate limits, you can turn on auto-recovery to proactively adjust concurrency levels. When rate limits are hit, the platform lowers concurrency to 1 and retries with a delay that doubles after every attempt (1 min, 2 mins, 4 mins, up to 1024 mins) until the Target concurrency level is reached again.

Navigate to Resources > Connections.
Select the Connection you want to edit.
Under the Advanced section, select the Auto-recover rate limit errors checkbox, if the default setting was deselected.
Enter a Target concurrency level based on your endpoint's API policy.
Select Save & close.

Tip

When using Celigo prebuilt connections to external applications, for example, NetSuite, Salesforce, it consider the rate/concurrency limits imposed by those endpoints.

Flow setting: Auto-resolve errors with the matching trace key

This setting automatically resolves repeated errors (duplicates) in a flow step and retries intermittent failures.

Feature	Action
Duplicate errors	Uses trace keys (unique record identifiers) to find duplicates. When a record is successfully processed or a newer error occurs for the same record in a flow step, older errors are marked as Auto-resolved in the flow step.
Intermittent errors	Initiates an auto-retry mode for failures classified as intermittent (for example, a temporary network outage).

Configure flow auto-resolution

In Flow builder, select the Settings button (gear icon) at the upper right.
Set Auto-resolve errors with the matching trace key to Yes, if the default setting was deselected.
Select Save.

Intermittent error retry schedule

If you turn on auto-resolution, the platform performs up to four retry attempts for intermittent errors:

Attempt	Lapsed time	Action
Initial	00:00	Error occurs; auto-retry mode initiated.
First	00:30	First retry attempt.
Second	01:30	Second retry attempt.
Third	03:30	Third retry attempt.
Final	07:30	Final retry attempt.

Manually resolve errors (single, batch, or bulk)

Step 1: Review and analyze errors

You can use the details available on the Errors page to better analyze your errors. The Errors page also provides an AI co-pilot, Ora, to help you to anlayze the errors. For more information, see the Errors page.

Review errors by classification

Classification identifies the type of error that's occurred. It makes it easy for you to examine and understand the error by also considering other error information availabe on the Errors page. Filters help you detect patterns and troubleshoot by any specific error type.

Classification	What you can do
Connection	Re-enter credentials/authentication for check access permissions for the account.
Duplicate	Correct the mapping in your flow step to prevent duplicate records.
Rate limit	Adjust the concurrency values or wait for rate limits to reset.
Too large	Decrease the page size in your flow settings, or enable chunking/pagination if that's supported in your endpoint, or pre-filter your data to exclude unnecessary fields.
Missing	Enter the required missing details in the source record.
Parse	Correct the Mapping logic or the `Handlebars` expression in the flow step.
Value	Check if your data matches the data expected by your endpoint. For example, a mismatch in date formats or number versus text formats.

Review errors by source

The source of an error points to the specific stage or component in the integration where the failure occurred. The sources that are typically listed include:

Source	Where you can find the errors
Export	Check the export preview for any issues in the extracted data from the source application.
Import	Check the import preview for any issues in the data being sent to the destination application.
Lookup / Data retrieval	Check for any failures during lookups or issues in reference data.
Transformation / Mapping	Check for any problems in field mappings, transformations, or data shaping logic.
Script / Hook	Check for errors in custom JavaScript (preMap, postMap, preSave, and so on).
Connection / Endpoint	Check for authentication, connectivity, or API-related issues from external systems. Review the endpoint documentation to resolve API issues.

These sources help you quickly pinpoint where in the integration the issue originated, so you can go directly to the relevant logs, mappings, or system configuration to resolve it.

Review errors by timestamp

The timestamp shows when an error occurred and allows you to filter based on a date/time range. Based on the time, you can check the audit logs to try and find out when, where, or who caused the error to investigate and fix the error.

Step 2: Edit retry data as required

After you've carfefully analyzed the error, check the you've selected the error row and modify the required field values before retrying the error to test the resolution. If the error is successfully resolved, make sure to update any values in the endpoint as required.

A blue dot on the box next to an error shows when someone edits and saves the retry data, but has not retried the error after making the change.

Step 3: Retry or resolve errors (single or batch/bulk operations)

You can manage your errors one at a time or perform batch or bulk operations to retry/resolve them. For more information, see the Errors page.

Retry: Select this option after you fix, for example, a connection or external data issue to re-process the record.
Resolve: Select this option to move an error to the Resolved tab without re-processing it. This is useful for "clearing noise" or handling errors you have addressed outside the platform.
Manage all: Select this option to retry all or resolve all errors as a bulk operation.