Default Routing in Designer

From Genesys Documentation
Jump to: navigation, search
This topic is part of the manual Designer User's Guide for version Current of Designer.

Learn how default routing works in Designer.

Related documentation:

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.

Des default routing http rest.png

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.

Des default routing data table.png

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.
Note that lack of proper error handling in External Services (API) and Business Controls blocks can show up as scripting errors. If an Assign Variables block relies on a data table result and tries to extract certain properties from it without proper guard conditions, this will generate a script error if the data table lookup fails and returns no data.

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.
Setting up Default Routing

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.
Terminating Calls skip Default Routing

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.

Comments or questions about this documentation? Contact us for support!