Looking for advice on a persistent 409 Conflict error when attempting to bulk import quality evaluation forms from ServiceNow into Genesys Cloud via the /api/v2/quality/evaluationforms endpoint. The integration is designed to sync form structures dynamically, but recent updates to the ServiceNow instance have triggered a race condition where the webhook payload arrives before the previous form deletion is fully propagated in Genesys Cloud. The error response body indicates that a form with the same name already exists, despite the pre-flight DELETE request returning a 200 OK status. I have verified the request headers, including the X-Genesys-Request-Id, and confirmed that the ServiceNow script includes a 500ms delay between deletion and creation calls, yet the conflict persists. The payload structure adheres strictly to the JSON schema defined in the Genesys Cloud documentation, with all required fields such as name, description, and sections populated correctly. The issue seems to be exacerbated by the asynchronous nature of the Genesys Cloud quality management service, where the deletion operation is acknowledged but not yet committed to the database when the creation request is processed. I have attempted to implement exponential backoff in the ServiceNow business rule, but the 409 errors continue to occur at a rate of approximately 15% of all sync operations. The environment is running Genesys Cloud version 2023-10, and the ServiceNow instance is Tokyo (Tokyo Release). I am considering switching to a polling mechanism based on the form’s lastUpdated timestamp to ensure idempotency, but I would like to explore other options first. Has anyone successfully implemented a robust error handling strategy for this specific scenario, particularly regarding the timing of form deletions and creations? Any insights into the internal latency of the quality management service or best practices for managing state transitions in this context would be greatly appreciated.