Just noticed that our automated incident creation workflow via Agent Scripting is consistently failing. The Architect flow triggers correctly in Architect. ServiceNow returns a 400 Bad Request. Payload validation passes in Postman. Using Genesys Cloud Data Action connector version 2.1.4.
The specific error returned from ServiceNow is INVALID_GRANT wrapped in a 400 response, suggesting the OAuth token refresh mechanism in the Data Action might be stale or misconfigured. However, the same Data Action works fine for read-only calls to the CMDB.
Here is the configuration block from the Architect flow step:
webhook_step:
name: "Create_SNOW_Incident"
type: "data_action"
action_id: "da_snow_inc_create_v2"
input_mapping:
short_description: "${conversation.summary}"
caller_id: "${contact.email}"
category: "Digital Channel"
subcategory: "WebChat"
urgency: "3"
timeout_ms: 5000
The data_action definition uses the standard x_gen_gcp.snow_incident table mapping. When I test this in Postman using the same ServiceNow instance credentials and identical JSON payload structure, the incident creates successfully with a 201 Created response. The issue seems isolated to the Genesys Cloud outbound call.
I have verified the MID Server connectivity logs. No network timeouts. The request reaches ServiceNow. The failure occurs during the initial handshake or payload parsing stage on the ServiceNow side, likely due to how Genesys Cloud formats the headers or encodes the body.
Has anyone encountered similar issues with Data Action webhook payloads being rejected by ServiceNow despite passing local validation? Looking for insights on header formatting or OAuth token handling within the Genesys Cloud Data Action connector.