I have Data Action that calls internal REST API to retrieve customer order history. The API returns JSON array where each order object has slightly different fields depending on the order type.
Example API response:
{
"orders": [
{ "id": "ORD-001", "type": "product", "productName": "Widget A", "quantity": 5 },
{ "id": "ORD-002", "type": "service", "serviceName": "Premium Support", "duration": "12 months" },
{ "id": "ORD-003", "type": "product", "productName": "Widget B", "quantity": 2 }
]
}
My Data Action output contract defines orders as an array of objects with all possible fields: id, type, productName, quantity, serviceName, duration. In Architect, I want to iterate through the array and extract the most recent order.
The Data Action execution fails with:
Output translation error: Cannot map field 'productName' - field not present in response element at index 1
The error occurs because the service-type order at index 1 does not have productName field. The Data Action output mapper expects every element in the array to have identical schema.
Is there way to handle arrays with mixed schemas in Data Action output mapping?
Nope. The Data Action output mapper is strictly typed - every element in an array must conform to the exact same schema. This is one of the most frustrating limitations and I have been complaining about it since the predictive routing beta.
The workaround is to move the schema normalization to the API side. If you control the internal REST API, modify it to always return all fields on every object, using null or empty strings for fields that do not apply:
{ "id": "ORD-002", "type": "service", "productName": null, "quantity": null, "serviceName": "Premium Support", "duration": "12 months" }
If you do not control the API, put a lightweight proxy in front of it. A simple AWS Lambda or Cloud Function that calls the real API, normalizes the response schema, and returns the padded result. Your Data Action points to the proxy instead of the original API.
Yeah it is an extra hop but it is 15 minutes of work and it permanently solves the mixed schema problem for any API you integrate with.
The proxy approach is the standard solution. An alternative that avoids the extra infrastructure: change your Data Action output contract to receive the entire orders array as a single String field instead of a typed array.
In the output contract, define:
ordersJson (type: String)
In the output mapping, use a JSONPath expression that serializes the array:
$.orders
With the translation map set to “JSON String” mode, the entire array is passed as a raw JSON string to the Architect flow. Then in Architect, use the JsonParse() expression function to extract individual values:
JsonParse(Flow.ordersJson, "$[0].productName")
This bypasses the strict schema enforcement entirely because the Data Action treats the output as an opaque string rather than a structured object. You lose compile-time type checking in Architect, but you gain full flexibility to handle any JSON structure.
I filed a feature request on the SDK GitHub (issue #1024) to add optional/nullable field support to Data Action output contracts. No movement on it yet.