Quick question about the specific payload structure required when triggering a ServiceNow incident from a Genesys Cloud Architect flow using the built-in ServiceNow integration. The environment is set to Europe/London, and we are running the latest stable release of the platform. The goal is to auto-create a ticket whenever a specific IVR node is hit, passing the conversation_id and caller_id directly into the short_description field.
The webhook configuration in Genesys is set to POST to the ServiceNow REST API endpoint (/api/now/table/incident). Authentication is handled via Basic Auth embedded in the header, which has been verified to work via Postman with identical credentials. However, when the flow executes, the ServiceNow side returns a 422 Unprocessable Entity error. The error payload from ServiceNow indicates that the ‘short_description’ field is missing or null, despite the Genesys Data Action clearly mapping the value.
Inspecting the raw request logs in ServiceNow, the JSON body arrives as:
{
"short_description": "Call from {{caller_id}} - Conv ID: {{conversation_id}}"
}
The variable substitution appears to happen correctly within the Genesys flow debugger, showing the actual values. Yet, the ServiceNow API rejects it. I have cross-referenced the Genesys documentation for the ServiceNow Data Action and ensured the content-type header is explicitly set to application/json. There is no mention of a required wrapper object or specific field naming convention in the current docs for this integration.
Is there a known issue with how Genesys serializes the JSON body for ServiceNow Data Actions, specifically regarding string interpolation within the payload? Or is there a specific header or format requirement for the ServiceNow REST API that is being overlooked in the standard Genesys connector configuration? The token generation seems fine, as a 401 would be the result of auth failure, but the 422 suggests a schema or parsing mismatch on the receiving end.
Does the Genesys ServiceNow Data Action require a specific JSON structure or content-type variation to prevent the 422 error on the ServiceNow side?