Default Routing in Designer
Contents
Learn how default routing works in Designer.
About Default Routing in Designer
Designer applications provide self service to interactions (voice calls, digital interactions) and route them according to the business logic. These applications may fail to provide these services due to a variety of reasons, which can negatively impact the end user experience and the ability to deliver a standard of interaction processing that aligns with business objectives.
This page describes Default Routing as it pertains to the voice channel on Genesys Multicloud CX. Basically, Default Routing acts as a fallback application for routing voice calls to an agent in the event that an application experiences a service failure, to ensure that these interactions are not lost. In many cases, the triggering of Default Routing can be avoided by improving the ability of applications to handle some common scenarios, which is described in Application resiliency.
Application resiliency
Designer applications are rarely self-contained. They almost always rely on data that is retrieved dynamically from multiple sources, such as data tables, customer CRM APIs, and others. As such, it is important to be aware that any data lookup is prone to failure and that applications must check for this condition and take it into account before proceeding forward.
A lookup failure may be considered as recoverable if the application can lookup another data source or provide a default value that satisfies the business logic and provides an acceptable level of service. In such cases, the application must test the outcome of each lookup and if a failure occurs, assign these defaults before moving on to subsequent lookups in a chain or with executing any business logic that relies on this lookup.
Other failures may be considered critical where it may not be possible to continue to provide the desired level of service, but even these cases should be handled by the application with an action such as routing to a route point or global skill.
Common failures that may be encountered by applications are described below. These cases must be handled in the Designer application to ensure these are handled correctly and do not trigger Default Routing.
External API fetch failures
APIs are called from the HTTP REST and Custom Service blocks. Both report on the outcome using the output properties in the Results tab. This outcome must be checked to confirm the API call succeeded before using its output. Failures can occur due to remote API issues, load, latency, or incorrect configuration.
Business Controls lookup failures
Business Controls (Data Tables, Business Hours, Special Days, and Emergency flags) are almost always external to applications. Successfully reading, or evaluating them in application logic, is not guaranteed. All Business Controls blocks (with the exception of Emergency) provide the status of the lookup using the Result tab variables in addition to output variables that provide the actual result the application logic is interested in.
In this example, the variable varLookupError will be set to true if the operation of looking up a data table encounters an error. In that case, varRoutingSkillsFromTable will not contain usable data, and referencing this variable from a routing block will generate an error.
Scripting errors
Designer uses a flavor of ECMAScript/JavaScript that can be embedded in blocks such as Assign Variables, Segmentation, and others. These scripts may have robustness issues that could lead to runtime errors when the script is evaluated. Certain block properties, such as Advanced Scripting in the Assign Variables block, will catch these errors and provide an outcome variable similar to Business Controls blocks to signal that there was a problematic evaluation of the script.
However, other block properties have stricter requirements for scripting expressions, and will jump to Finalize if the application runs and encounters an issue with the expression. These expressions are normally much simpler than scripts entered in Advanced Scripting tab of Assign Variables blocks, but it is still essential to ensure they are robust. For example, if a data table lookup fails, and the next block assumes that the lookup was successful and tries to operate on the returned data, it will run into an error and cause unintended consequences.Platform resiliency
Genesys Multicloud CX is a highly reliable and scalable platform. However, it is important to put mitigation in place for Designer applications for the unlikely event that the platform experiences technical issues and cannot reliably run these applications. This obviously falls into the critical category and will rely on Default Routing to continue routing the call to a global skill or designated route point.
Default routing
Default Routing relies on a different, simple, and standalone application. It is deliberately kept simple to make it more resilient. This application may be another Designer application which can be edited and managed from Designer, or it can be an IRD System application that contains multiple enhancements to handle a number of platform failure scenarios, as well as failures in Designer application logic.
Here's a brief comparison of these two application types:
| Designer Application | IRD System Application |
|---|---|
| Managed using Designer. | Cannot be managed by users of Designer. |
| Can support business logic, such as LOB separation. | Generic handling. Application is kept simple for robustness. May not support LOBs/departments/divisions. |
| Will be triggered when applications experience errors. | Will be triggered when applications experience errors. |
| May be affected by platform issues that affect Designer applications. | More likely to be resilient if platform issues affect Designer applications. |
Default routing cannot be set up directly in Designer and must be performed by Genesys. To learn more, contact your Genesys Representative.
In addition to handling application errors, Default Routing also detects if there is no audio playback from the Designer application during an active call and will initiate after 10 seconds of silence. This limit is not configurable and the application logic must ensure audio is played at all times and that silences are kept to a minimum.
Here are some suggestions for maintaining audio playback to avoid prolonged periods of silence:
- Play a prompt as soon as possible at the beginning of the application. Keep processing in the Initialize phase limited to under 2 seconds, ideally less than 1 second.
- In Self Service, play a generic prompt first, and only then proceed to business controls checks.
- Do not daisy-chain multiple lookups without inserting some audio in between.
- Keep external API call timeouts less than 10 seconds and enable Play fetch audio, which plays specified audio during the entire lookup.
It may be obvious, but if the Designer application terminates the call, Default Routing will not be triggered. If the application logic decides certain lookup failures are critical or it has encountered another critical errors, it can simply jump to Finalize using a GoTo block. This allows Default Routing to be initiated after a certain timeout.