Genesys Cloud - Main

 View Only

Sign Up

  • 1.  Handling timeouts in Data Actions called from Architect

    Posted 5 days ago

    When a Data Action takes too long or the external API is down, what's your preferred pattern in Architect? Do you retry inside the flow, route to a fallback queue, or play a message and continue? Would love to hear how others keep the customer experience smooth when integrations fail.


    #ArchitectandDesign

    ------------------------------
    Vinicius
    ------------------------------


  • 2.  RE: Handling timeouts in Data Actions called from Architect

    Posted 5 days ago

    Hi VInicius,

    In our environment, we generally use Architect error handling rather than allowing the interaction to fail when a Data Action times out or an external API is unavailable.

    We have a centralised error-handling approach where failures are routed to a dedicated error path. Depending on business hours and the use case, the interaction can be sent to a fallback queue for agent assistance or played an appropriate message if no support is available. 

    Our preference is to keep the customer journey moving whenever possible and avoid repeatedly retrying integrations that are already unavailable. For critical transactions, routing to an agent is usually a better experience than leaving the customer stuck in the flow.

    I'd be interested to hear how others handle transient API failures. Are you seeing success with retries, caching, or alternative lookup sources before falling back to an agent?



    ------------------------------
    Akhil
    ------------------------------



  • 3.  RE: Handling timeouts in Data Actions called from Architect

    Posted 5 days ago

    Hi Vinicius,

    My preference in Architect is to handle the Failure and Timeout paths explicitly and keep the customer moving. If the lookup is optional, I'd continue with the normal route; if it's essential to the next step, I'd play a brief message and transfer to an agent.

    I'd consider a limited retry for a temporary lookup failure, but avoid repeated attempts when the external service is down.



    ------------------------------
    Phaneendra
    Technical Solutions Consultant
    ------------------------------



  • 4.  RE: Handling timeouts in Data Actions called from Architect

    Posted 4 days ago

    We have used a loop in architect if we get timeout or failure. Max 3 loop with some seconds between is normally enough.



    ------------------------------
    Eystein
    Systemutvikler Genesys Applikasjonsspesialist
    ------------------------------



  • 5.  RE: Handling timeouts in Data Actions called from Architect

    Posted 3 days ago

    Hi Vinicius,

    I always try to keep the call proceeding within the flow with proper error handling. Most of the time I work with fallback values that step in in case of a data action can not deliver a value. Most of my data action calls are not critical, so that is possible. At the end of my flows is always a failure routing to a certain queue that is not reached, if the call runs through properly. I have a milestone there to monitor, if and how often that failure routing is used.

    I suggest an error handling (like transfer to a fallback queue or something like that) for critical cases. 



    ------------------------------
    Christoph
    Produktmanager Kunden-Dialog-Center
    ------------------------------



  • 6.  RE: Handling timeouts in Data Actions called from Architect

    Posted 3 days ago

    Hi Vinicius,

    We don't retry inside the flow, and we don't send the call to a fallback queue. Instead, we make every integration fail safe. Before each Data Action, we set the output variables to safe default values. The Failure and Timeout paths have no actions, so the call simply continues as if no data came back, and the caller never notices the problem. We also check every level of the JSON response with nested IsSet() before reading anything, even on Success, because an incomplete response can break the flow just as badly as an outage. We never use Disconnect on errors. If an API is down for a longer time, we turn on a contingency message per module from a data table, so we can warn callers without republishing the flow. Navigation markers then show us where the integration failed. Retries mostly add silence for the caller, so we'd rather keep the call moving.



    ------------------------------
    Diego
    NA
    ------------------------------



Related Content