You can manage errors in flows by configuring automatic recovery settings if disabled, or manually retrying and resolving specific records. This article covers how to identify error types and use both automated and manual tools to clear your error queue.
If you want to manually resolve errors, you can focus on the Errors page is the first stop for error resolution; and, if requried, use other troubleshooting options in the Celigo platform to investigate errors.
When you suucessfully retry/resolve errors, the error count shows a decrease on the step in flow builder & completed flows in the dashboards; and, the error resolution count increases in the User-resolved or Auto-resolved columns in the dashboard
Note
If you think any error you resolve will help other platform users, you're welcome to share your solution in the Celigo Community – Connective. Or, if you’re stuck with an issue, you’re welcome to ask a question in the Community or raise a Support ticket to resolve the issue.
-
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..
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.
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.
This setting automatically resolves repeated errors (duplicates) for all steps in a flow 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). |
If you turn on auto-resolution, the platform performs up to four retry attempts for intermittent errors:
If an error requires a data change or manual fix, you can manage it from the Errors page. Perform the following actions on the Open errors tab.
-
Retry: Select this option after you fix, for example, a connection or external data issue to re-process the record.
-
Resolve: Select this 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.
-
Edit retry data: Select an error row to modify the record's field values before retrying. A blue dot shows on the box next to an error when anyone edits and saves the retry data, but has not retried the error after making the change.
Review your errors and troubleshoot them based on classification, source, or timestamp. You can correct them by making changes in the Retry data on the Errors page itself and then manually retry them. Based on your requirements, manage errors individually, or as batch or bulk operations. For more details, see view and troubleshoot errors – Errors page.
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 |
|
Value |
Check if your data matches the data expected by your endpoint. For example, a mismatch in date formats or number versus text formats. |
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.