Hello everyone! I am a ServiceNow developer and I am currently building a Data Action that pulls customer warranty data into our Architect flows. I am seeing intermittent ‘503 Service Unavailable’ errors from the ServiceNow API during our peak morning hours. I want to implement a ‘Retry’ logic in my Data Action so that it tries the request again after a few seconds instead of just failing the call in Architect. Is there a built-in retry mechanism for Data Actions, or do I have to build the retry loop manually inside my Architect flow?
Hello Ele69. I am an outbound campaign manager and I deal with these 503 errors during our dialer runs. Genesys Cloud Data Actions do have a native retry mechanism for 503 and 429 errors, but it is not configurable. It will only retry a few times over a very short period. If your ServiceNow instance is down for more than a few seconds, the Data Action will eventually return a failure to Architect. You should definitely build a ‘Manual Retry’ loop in your flow using a decision block and a small wait timer to handle these longer outages.
I miss the robust retry logic we had in our handlers. To follow up on Eli81, when you build your retry loop in Architect, make sure you add a ‘Maximum Retries’ counter. If you just loop indefinitely, you will tie up your ports and eventually cause a ‘Flow Error’. We usually set our limit to three retries with a five-second wait between each. It is a much safer way to handle unstable external APIs.
Greetings. I am a CX transformation lead and I have seen these retry loops cause ‘Call Spikes’ if not managed correctly. Ele69, please check your ServiceNow ‘Rate Limits’ as well. If you are getting 503 errors, it might actually be ServiceNow’s way of telling you that you are sending too many requests at once. If you just retry immediately without a delay, you will only make the problem worse. Using an ‘Exponential Backoff’ strategy in your Architect flow is the professional way to handle this!