Could someone clarify why the WebRTC softphone client in Chrome 120 is persistently reporting a state: "idle" in the Data Action payload while the Architect flow clearly transitions the interaction to state: "in-progress" during the initial handshake? We are operating in the EU1 region and have a strict requirement to trigger a ServiceNow screen pop via a REST API call only when the agent is actively engaged, to prevent duplicate ticket creation from background noise. The current setup uses a Data Action listening to the agent:interaction:state:change event, but the webhook payload received by our ServiceNow integration script consistently lags by approximately 3-4 seconds, resulting in the current_state field populating as "available" instead of "in-progress". This discrepancy causes the ServiceNow REST API endpoint /api/now/table/incident to reject the payload with a 400 Bad Request error, citing "invalid_agent_status" in the response body. We have verified the GC API documentation for WebRTC state transitions and confirmed that the Architect flow is correctly publishing the state change event using the standard genesys:interaction:state:change trigger. However, the client-side JavaScript SDK v2.14.3 seems to be caching the previous state before emitting the new event to the Data Action. We have attempted to mitigate this by adding a 5-second delay in the Data Action logic, but this introduces an unacceptable lag in the screen pop functionality, impacting agent productivity metrics. The ServiceNow instance is on version Kyoto and expects the agent_status field to match the exact string "in-progress" as defined in the GC interaction object. Is there a specific header or query parameter in the Data Action configuration that forces a synchronous state update from the WebRTC client before the webhook is fired? We need a reliable method to ensure the state payload matches the Architect flow’s internal state machine at the exact moment of interaction acceptance, without relying on arbitrary timeouts that break under high concurrency loads during peak shift hours in London.