Implementing Robust Data Action Retry Logic in Architect Tasks

I am currently building a ‘Patient Check-In’ flow in Architect. We use a Data Action to pull patient details from a legacy system that is occasionally ‘Flaky’ and returns a 504 error. I want to implement a ‘Retry’ logic in my Architect flow that tries the Data Action three times with a two-second delay between each attempt before finally giving up. Is there a way to do this using a ‘Loop’ in Architect without making the flow too complex for our other admins to maintain?

I have built several of these retry loops for our custom agent desktop. In Architect, the cleanest way to do this is to use a ‘Task’ with a ‘Loop’ block. Initialize a ‘RetryCount’ variable to zero. Inside the loop, call your Data Action. If it fails, increment the counter and use a ‘Wait’ block before looping back. If the counter hits three, exit the loop and send the call to a failure handler. It is a very standard pattern and any experienced admin will be able to follow it!

I want to add a note about the ‘Customer Experience’. While retry loops are great for stability, they add significant ‘Silence’ or delay for the caller. If your Data Action takes two seconds to time out, three retries plus the waits could mean the patient is sitting in silence for over ten seconds! You should always play a ‘One Moment Please’ message before you start the retry loop to ensure the caller knows the system is still working on their request. It is a small detail but it makes a huge difference in our CSAT scores!