You can add response mappings to capture data returned from an import within your flow. For flows that have multiple imports, response mappings allow you to insert the response data of an import back into your source record so that you can reference that data in subsequent steps of your flow. For example, if an application automatically assigns customer IDs to newly imported customers, and the assigned customer IDs are included in the response, you can add those field values to the source record for use in future steps.
Follow the steps below to configure response mapping:
- Click + on the import step, and click the mappings (
) button on the right.
- The field mappings you define will be added as new fields or replace existing fields if those fields already exist in the source record. Use the Import response field drop-down list in the Edit response mapping panel to select the fields from the response you want to map back to the source record.
- id: the ID of the record just imported.
- errors: any errors from the record that was processed in this step.
- ignored: a Boolean true or false. The value is true if the record processed through this step was ignored. Otherwise the value is false.
- statusCode: the status code that resulted from processing the record through this step.
- _json: returns the full JSON formatted response of the import. For example,when importing customers into Shopify, Shopify might return the customer record that was created in their system as part of the response, and that customer record might include an automatically-assigned sales representative ID. You can use _json to retrieve the sales representative ID.
- dataURI: when possible, this returns the link to the data that was created or updated by the import.
- headers : the header values of the response.
- Enter the Source record field at the right to hold the data that will be merged back into the source record for use later on in the flow. New fields will be added to the source record unless you specify an existing field. If you use a field that already exists in the source record, it will be overwritten.
- Click Save & close.
Results mapping is similar to response mapping, but instead of returning the response after an import, results mapping allows you to merge the resulting records returned by a lookup step in your flow back into the source record. The returned lookup records can then be used in steps later on in the flow.
To configure results mapping,
- Click + on the lookup step, and click the mappings (
- The field mappings you define will be added as new fields or replace existing fields if those fields already exist in the source record. Click in the Lookup response field in the Edit results mapping panel to select the fields from the response you want to map back to the source record.
- data: the records returned by the lookup step.
- errors: any errors from the record that was processed in this step.
- ignored: a Boolean true or false. The value is true if the record processed through this step was ignored. Otherwise the value is false.
- statusCode : the status code that resulted from processing the record through this step.
- dataURI: when possible, this returns the link to the data that was gathered by the lookup.
- Choose a field in the Source record field on the right to hold the data that will be merged back into the source record for use later on in the flow. New fields will be added to the source record unless you specify an existing field. If you use a field that already exists in the source record, it will be overwritten.
- Click Save & close.
If you have multiple destination flow steps in your flow, you can configure the way that each intermediate destination step handles failed records.
Click to define the way that failed records will be handled by an intermediate destination flow step.
Handle record-level import failures
When individual records fail during an import or a flow run stops before all records are processed, use these settings to identify the failure, capture the endpoint response, and recover affected records.
- Isolate failed records: On the import step, set What should happen to a record if the import fails? to Proceed to the next application regardless. This captures the failed record as a record-level error while allowing other records to continue processing. For HTTP imports, use a batch size of 1 to isolate each payload.
- Recover records after a delta export: A downstream import failure does not roll back the delta export checkpoint. As a result, failed records may not be included in the next scheduled run unless the source record changes. Retry the records from Error Management, or use a reconciliation or backfill flow to resend records that do not have a completion marker. Add the completion marker only after the destination confirms a successful import.
- Capture the endpoint response: Basic logging may not display the endpoint's error response in the dashboard. Temporarily enable debug logs on the flow step to capture the HTTP request and response. You can also configure HTTP response or error parsing on the import so that application errors are reported for individual records.
Important
If the error Source is Internal, such as NoSuchKey ("The specified key does not exist") or page_not_found, the error originates within the Celigo platform rather than from the flow configuration or endpoint. Use Celigo Ora or available diagnostic tools to identify the error source, and contact Celigo Support for further assistance.
Pause here until someone can fix the error
When a record causes an error, by default, the Pause here until someone can fix the error option is selected to stop the flow from sending the failed record to any subsequent flow steps until the error is fixed. The failed record will be held here so that you can fix and retry it. Upon a successful retry, the record will then proceed to any additional flow steps.
Click Proceed to the next application regardless to push records that contain errors to subsequent flow steps regardless of whether or not the record produces an error during this flow step. The failed record can still be fixed and retried for this flow step, but if it didn't fail on any additional flow steps, it won't be pushed to those additional steps upon successful retry. This is the preferred choice if, for example in NetSuite use cases, you are sending inventory update records to multiple webstores or marketplaces. If the record fails on this step, you might still want that record to proceed to any subsequent steps in the flow so that the other stores and marketplaces can get the update.