Just noticed that our automated ticket creation workflow is failing intermittently when pushing rich context from a digital channel interaction into ServiceNow. The setup involves an Architect flow capturing a chat:ended event, which then triggers a Data Action configured to call a custom ServiceNow REST API endpoint for incident creation.
Context:
Environment: Genesys Cloud (EU-West), ServiceNow (London Release)
Flow Version: v7.2
Data Action Type: HTTP Request (POST)
Payload Structure: The body contains nested objects for customer details and interaction history. Specifically, we are mapping the conversationId, participantId, and a serialized JSON string of the last 10 message blocks into the work_notes field.
The issue arises when the serialized message block exceeds approximately 2KB. The Genesys Cloud logs show the Data Action executing successfully, but the response from ServiceNow is a 400 Bad Request. The error payload returned by ServiceNow indicates: JSON parse error: Unexpected character ('\' (code 92)). This suggests an escaping issue within the nested JSON string being constructed in the Architect flow’s data mapping stage.
I have verified the raw request payload using the Genesys Cloud trace tool. The output shows that double quotes within the message text are being escaped as \", but when this string is embedded within the main JSON body sent to ServiceNow, it seems the escaping is either double-encoded or malformed, causing the ServiceNow REST API parser to choke.
We are not using any custom headers that might interfere with content-type negotiation. The Content-Type is explicitly set to application/json. I have attempted to use the encode() function in the Architect flow to handle the string, but that results in URL-encoded parameters, which ServiceNow rejects for the JSON body.
Question:
What is the recommended pattern for safely embedding complex, user-generated text strings (containing quotes, newlines, and special characters) into a JSON payload via a Genesys Cloud Data Action? Is there a specific function or formatting requirement in the Architect flow to ensure the JSON structure remains valid before it hits the ServiceNow endpoint, or should we be handling this escaping logic on the ServiceNow side via a script include?