Lookups enrich data by retrieving additional information from external sources that can then be merged with the initial source data. When a lookup returns errant records, you can use a preSavePage
script to effectively handle and ignore errors in the retrieved lookup data before merging it with the initial source record data.
A lookup runs on each incoming source record, and the returned lookup data for each record triggers the preSavePage
script before merging it with the record's initial source data. Handling errors during this process requires special consideration to avoid issues such as duplicate errors or improper error handling in the error management dashboard.
Important
-
Avoid using
newErrorsAndRetryData
for lookups: Do not use thenewErrorsAndRetryData
array in the response for lookuppreSavePage
scripts because the primary record is the source record, not the lookup results. If you were to returnnewErrorsAndRetryData
objects for multiple lookup results of a single source record, each error would be treated as a separate issue in error management. This leads to confusion since retrying these errors would process each lookup result as if it were an independent record rather than part of the single source record. -
Avoid adding new errors to the
errors
array: Similarly, adding new errors to theerrors
array can cause multiple errors to appear in the error dashboard for the same source record leading to the same problem of treating a single source record as if it has multiple independent errors. Instead, the Celigo platform will automatically stop paging for additional results for a particular source record if an API error is encountered. For example, if the first API call succeeds but a subsequent call fails, the flow will stop attempting to retrieve further data, and a single error will be logged.
The two main strategies for handling errors in lookup preSavePage
scripts are:
If you encounter an error that shouldn’t halt the flow (for example, 404 Not Found
for a resource that no longer exists), you can ignore it to allow the flow to continue. This is useful when you want the flow to proceed even if no results return from that record's lookup request.
function preSavePage(options) { let errors = []; if (options.errors.length > 0) { for (let e of options.errors) { if ( e.code == "404" && e.message == '{"errors":["The requested URL or resource could not be found."],"error_type":"not_found"}' ) { continue; // Ignore this specific error } else { errors.push(e); // Keep other errors } } } return { data: options.data, errors: errors, abort: false, newErrorsAndRetryData: [], }; }
The above script checks for a 404 error with a specific message and ignores it, allowing the process to continue without interruption. Other errors are preserved and passed along.
Modifying error messages:
You may want to modify the error message returned by the lookup API to make it clearer for end users or to provide specific instructions on how to handle the error.
function preSavePage(options) { if (options.errors.length > 0) { for (let e of options.errors) { if ( e.code == "404" && e.message == '{"errors":["The requested URL or resource could not be found."],"error_type":"not_found"}' ) { e.message = "The resource you’re looking for could not be found. Please verify the input and try again."; } } } return { data: options.data, errors: options.errors, abort: false, newErrorsAndRetryData: [], }; }
The above script customizes the error message to provide clearer guidance to the user. Use this to reduce support queries or to mak error management more intuitive.
Final considerations
-
Proceed with errors: If you have a setting to proceed regardless of errors, any valid data returned in the
data
array will be passed downstream as long as you have appropriate results mapping. -
Handling errors gracefully: Use the strategies outlined above to ensure that errors are managed effectively without creating additional issues in the error management dashboard.
Comments
Article is closed for comments.