The Celigo platform includes a range of advanced functionalities designed to help you analyze integration flow runs and manage potential system anomalies. Among the capabilities for handling errors are interactive dashboards that swiftly provide insights into your integration performance, coupled with utilities to pinpoint and effectively address any unresolved errors.

However, it can be incredibly overwhelming if you’re not familiar with the codes and terminology used in the error list. Even with Celigo’s user-friendly interface which attempts to simplify very complex integrations, you may still find you need help with your existing integrations.

In this article, we’ve created a step-by-step guide on how to identify the error source, identify the error classification, identify the error category, and troubleshooting tips of how to address any unresolved errors.

Contents

• The Error Process
• Identify the Error Source
• Identify the Error Classification
• Identify the Error Category
• Troubleshooting Connection Errors
• Troubleshooting Permissions Errors
• Troubleshooting Data Errors

Step 2 – Identify the error classification

Once you have identified the error source, you must then identify the error classification. When you view the list of errors encountered in a flow, each open and resolved error is labeled according to its type, or “classification.” Errors are categorized according to their properties, such as the code, message, and source fields.

The Classification column helps you quickly recognize and filter errors, even when the escaped JSON or third-party app error messages are difficult to read.

Errors are automatically placed into one of the following seven read-only classifications; if the value is blank, then none of them applies.

Classifications

• Value 
• Missing
• Connection
• Intermittent
• Governance
• Parse
• Duplicate

Based on an error’s properties (such as code, message or source), errors are automatically placed into one of these classifications. Click on the toggles below for specific examples of errors per classification.

VALUE

Sample errors:

• A phone number isn’t formatted as expected.
• A new value is sent for a status field that can’t be changed.

MISSING

Sample errors:

• A required field is empty or missing
• A resource can’t be found at the file path provided

CONNECTION

Sample errors:

• The user doesn’t have permission to access or edit a record.
• An incorrect username or password was used.

INTERMITTENT

Sample errors:

• A connection timed out.

GOVERNANCE

Sample errors:

• An API request exceeds the number allowed in a period of time.
• A request or operation too too long.

PARSE

Sample errors:

• A token doesn’t conform to the expected syntax of the input language.

DUPLICATE

Sample errors:

• The destination already has an exisitng record.
• The lookup system finds more than one matching result.

Step 3 – Identify the error category

Most errors fall into one of the three categories:

• Connection Error
• Permissions Error
• Data Error

By using an error’s source and classification, you can determine which category it falls under. 

If the error source is internal, the most likely causes are:

• Malformed handlebar {{ expression
• Bad custom javascript
• Other invalid data in the configuration

In these cases the error classification can be blank and data error is often the category.

If the error source is external, the error will likely fall into any of the three main categories. You can use the error classification to help you determine which category.

The table below illustrates the categories and the error classifications each can include.

This is meant to serve as a guide to uncovering the errors, but some errors may not fall into these common categories and are unique to the application’s external system. In those instances, refer to an application’s API documentation for specific information about that application.

Step 4 – Troubleshooting

With the error category identified, you can proceed using troubleshooting steps for that category. Let’s begin by looking at connection errors. 

 Troubleshooting Connection Errors

Connection errors usually happen when trying to connect to an endpoint. Some of these errors may be due to a server issue, a time-out, a system outage, or a URL change.

Here is what you should do if you encounter a connection error, click on each toggle for a detailed description with images to support.  

 Troubleshooting Permission Errors

Permission errors occur when part of the flow has insufficient access to a record or object it requires to update. Below is how we suggest you handle these types of errors. 

 Troubleshooting Data Errors

Errors classified as Parse, Value, or Duplicate are often types of data errors, which are the most common type of error.

Data errors are generally caused by data not formatted in the way a destination is expecting, missing data, and mismatched IDs. Messages for this error category can include the following phrases:

• Could not compile… expecting…

• Required parameter/field missing or invalid

• Data items invalid/do not exist/not found

• Please enter value for…

• Record with this ID already exists

• Response failed using…

• Parse error on…

In Conclusion…