WFM Scheduling API Data Action Fails with 422 on ServiceNow Incident Creation Trigger

Can anyone clarify why a Genesys Cloud Data Action configured to create a ServiceNow incident via POST /api/v2/wfm/scheduling/groups is consistently returning a 422 Unprocessable Entity when triggered by a webhook from a digital channel conversation? The integration is designed to automatically generate a ServiceNow ticket whenever a scheduling conflict is detected in the WFM module, using the genesys-cloud integration framework. The webhook payload includes the user_id, group_id, and conflict_type, but the ServiceNow REST API endpoint rejects the request with a validation error stating that the cmdb_ci field is missing, even though the Data Action mapping explicitly sets this field to the value derived from the group_id. The Architect flow is set to wait_for_response with a timeout of 30000 milliseconds, and the debug logs show that the outbound request to ServiceNow is successful in terms of connection, but the payload structure seems to be malformed upon arrival. I have cross-referenced the Genesys Cloud WFM API documentation and the ServiceNow REST API guide, and the field mapping appears correct. The issue persists across multiple test users in the Europe/London timezone, suggesting it is not a localized configuration problem. The ServiceNow instance is running version Washington DC, and the Genesys Cloud tenant is on the latest release. I have verified that the OAuth token used for the Data Action has the necessary incident.create permissions. The error response from ServiceNow includes a detailed breakdown of the missing fields, but the cmdb_ci field is clearly present in the outgoing JSON payload as captured by the network trace. Is there a known issue with how Genesys Cloud serializes nested objects in Data Actions when interfacing with ServiceNow? Or could this be related to the way the WFM API formats the group_id before passing it to the ServiceNow endpoint? Any insights into resolving this 422 error would be greatly appreciated, as it is blocking our automated ticket creation workflow for scheduling conflicts.