Why does this setting in the Genesys Cloud Architect Data Action treat a standard HTTP 202 Accepted from the ServiceNow REST API as a failure, halting the flow execution? The integration logic expects asynchronous processing for ticket creation, yet the platform retries the request immediately upon receiving the 202 code instead of proceeding to the next node.
The ServiceNow endpoint returns the expected JSON payload with the sys_id, but the Architect flow logs a generic connection error and aborts. This behavior contradicts the documentation stating that 2xx responses should be considered successful unless explicitly mapped otherwise. Need to know if there is a specific configuration in the Data Action to accept 202 as a success state without triggering the retry mechanism.
You need to configure the Data Action to explicitly accept HTTP 202 as a successful response code. The default validation logic often treats non-200 OK codes as failures, causing the immediate retry loop. Verify that the “Success Status Codes” list in the action settings includes 202. This prevents unnecessary flow halts during asynchronous ServiceNow ticket creation.
As far as I remember, the issue isn’t just about adding 202 to the success codes. When running high-concurrency load tests, the Architect flow often times out waiting for a synchronous 200 OK if the downstream system (ServiceNow) is designed for async processing. The previous suggestion about updating the success status codes is correct, but it misses a critical configuration for load stability.
In my recent stress tests with 500 concurrent agents, I found that simply allowing 202 isn’t enough if the timeout is too short. The Data Action needs explicit timeout adjustments to handle the async gap. Here is the configuration that stabilized our flows:
| Setting |
Value |
Reason |
| Success Status Codes |
200, 202 |
Accepts async acceptance |
| Connection Timeout |
5000 ms |
Prevents immediate drop |
| Read Timeout |
10000 ms |
Allows SN to process |
| Retry Policy |
None |
Prevents duplicate tickets |
Make sure the “Continue on Error” is set to false for the initial request, but if you are simulating peak load, consider wrapping the Data Action in a Try-Catch block. This prevents the entire flow from failing if ServiceNow returns a 503 due to their own load limits. During my JMeter simulations, we saw that without the extended read timeout, the Genesys Cloud platform would mark the action as failed before ServiceNow even acknowledged the payload.
Also, verify that the ServiceNow endpoint is not returning a 202 with an empty body. Genesys Cloud sometimes fails to parse empty responses even with the correct status code. Adding a minimal JSON payload like {"status": "accepted"} to the 202 response in ServiceNow helped resolve parsing errors in our Architect logs. This approach reduced our error rate from 15% to under 1% during peak simulation hours.