Trying to understand the specific validation logic triggering a 422 Unprocessable Entity response when executing a Data Action within a complex Architect flow designed for outbound campaign qualification. The integration targets a legacy CRM via a custom REST endpoint, and while the initial authentication handshake succeeds with a 200 OK, the subsequent payload submission fails consistently. The error payload returned from the target system indicates a mismatch in the expected schema for the ‘agent_id’ field, which is being populated dynamically from the Flow Data. The Data Action is configured to map the ‘Agent.ID’ system variable directly to the JSON body, yet the receiving application rejects the value as invalid. This issue manifests exclusively during peak hours in the Europe/Paris timezone, suggesting a potential correlation with increased latency or concurrent session limits affecting the data transformation layer within Genesys Cloud. The flow architecture involves a series of decision nodes that filter calls based on queue occupancy before routing to the Data Action, which updates the CRM record prior to connecting the agent. The problem is not present in the flow preview mode, but occurs reliably in the production environment when the flow is triggered by live inbound traffic. The Data Action logs show the request body is formatted correctly according to the OpenAPI specification provided by the vendor, including proper Content-Type headers set to application/json. However, the 422 response persists, preventing the successful update of customer records and causing the flow to fall back to a default voicemail prompt. The business impact is significant, as agents are unable to access real-time customer history during the call, leading to increased handle times and reduced first-call resolution rates. The environment is running the latest version of the Genesys Cloud platform, and the Data Action has been tested independently using Postman with identical payloads, which succeed without error. This discrepancy between manual testing and automated flow execution points to a potential issue with how system variables are resolved or encoded during runtime. The team requires clarification on whether there are hidden constraints on data types or character encoding when mapping system variables to JSON payloads in Data Actions, particularly for non-ASCII characters that may be present in agent identifiers. Additionally, guidance on debugging the exact payload sent by the Data Action at the time of failure would be appreciated, as the current logging capabilities do not expose the raw request body in the event of a 422 error. The goal is to ensure seamless integration between the contact center platform and the CRM system, maintaining data integrity and operational efficiency across all queues.