Does anyone know how to correctly map legacy Zendesk ticket fields to Genesys Cloud custom attributes within an Architect flow? The flow executes without error but the resulting interaction lacks the expected data points, specifically the custom tags we relied on for routing in Zendesk. We are using the standard Web Chat channel and have verified the schema in the integration settings matches the Zendesk export. The issue appears to be in the Set Data node where we reference the incoming payload. In Zendesk, these were straightforward tag assignments, but here the JSON structure seems to require explicit path definitions that aren’t documented clearly for migration scenarios. We need to preserve the exact metadata structure for our French support team’s reporting requirements.
The root of the issue is likely not the Architect flow itself, but how the payload structure is being parsed before reaching the Set Data node. When dealing with high-concurrency Web Chat streams, the incoming JSON object from Zendesk often nests ticket fields deeper than expected. If the path reference in the Set Data node doesn’t account for this nesting, the variable returns null, resulting in empty custom attributes.
- Inspect the raw incoming payload in the Architect flow debug logs. Look for the exact JSON path to the
tagsorcustom_fieldsarray. - In the Set Data node, use a dynamic expression to flatten or extract the specific field. For example, instead of referencing
$.tags, try$.ticket.custom_fields.tags. - Add a simple JavaScript step before the Set Data node to log the payload structure. This helps verify if the data is arriving correctly from the integration.
- Ensure the custom attribute in Genesys Cloud is defined as a
stringorarraytype matching the Zendesk output.
This approach isolates the mapping error from potential API latency issues, which is crucial when scaling up concurrent sessions.