Event Handlers feature allows to create configurations which can handle the following:
the occurred errors during the Dialog that may cause the unintentional end of conversation
the cases when the caller wants to repeat the conversation or start it over from a certain step
It is all possible due to Error and Repeat functions of the Event Handlers feature.
Error Handlers function
The Error function of the Event Handlers allow channeling a conversation to a preconfigured Flow that will be played once the predefined error happens. Since the Error Handlers help managing multiple types of errors, you can configure different Flows to cover the possible scenarios at any point of the conversation.
For example, if the caller doesn’t respond to a question asked by a certain miniApp a number of times, it is possible to build a Flow and configure the Announcement miniApp inside containing the “Please, repeat!” message. You can then place it in the Error Handler dropzone, so this Flow will be played when this exact error happens, so the conversation will still be logically channeled.
It is possible to configure a default Error Handler with a Flow that will be played when any type of error appears. Also, define the error type and the miniApp it will occur in, and configure an Error Handler with a Flow that will handle it respectively. Multiple Error Handlers can be applied at the same time.
Orchestrator provides all miniApps error types found in the Fail Exit Reasons document.
Configure default Error Handler
Create a Flow that will be used for the Error Handling purpose. Build a Flow, fill in the corresponding fields, and click Save when finished.
2. This Flow can contain any building block. For example, if the Announcement miniApp is selected, when any type of error happens, it will be played. Configure it in the OCP miniApps like you did in the Getting Started section, to ask the caller “Please repeat!”, and drag and drop it onto the canvas.
3. Configure the miniApp values accordingly and click Save.
4. Click the Event Handlers to open the drawer on the right.
5. In the Errors tab, drag and drop a configured Flow into the dropzone. This Flow will be played any time the event happens: This flow will be executed if no other event handler matches.
6. If you want to change the Flow’s setting or remove it, click the Options icon next to the Flow’s name, and choose Configure, or select Remove if you want to delete it.
If selecting the Configure option, it is possible to change the Flow’s settings by adding or deleting them. Also, note that some inputs and outputs can be marked as Optional. Read about the Flow’s Optional Fields for more information.
7. If the process went successfully, the following message appears.
If any type of error happens at any point of the conversation, the default errorHandler with the preselected Flow will be played.
Configure specific Error Handler
Click the + Add Handler button to select any specific type of error or add multiple error types to be handled.
2. When the dropdown menu with the error types opens, select one or more types of error. Note that the error types are listed alphabetically.
3. Select the Event Source from the lower dropdown menu. The Event Source allows to select the miniApps the error can occur in and contains the list of all the miniApps that are used in the Dialog Application. It is possible to select multiple Event Sources for multiple Types of event to be handled by one Flow.
4. Select a Flow from the Flows left sidebar menu, and drag and drop it to the dropzone to be played once the error type occurs in the preselected miniApp. Click Save to finish.
It is possible to change the output data of the Flow in the Error Handlers, so it could be later used to execute Transfers from this Flow.
To change the output of the Flow, follow the steps below:
Click the Options menu icon in the right upper corner of the Flow, click Configure.
2. In the opened form, change the output value.
It is possible to have different combinations of the Error Handler at the same time. If there are multiple Error Handlers, a priority of execution is set, to avoid overlapping. For example what will happen if there is a Handler with error type MaxNoInputs and the other one with source miniApp_1 and miniApp_1 exits after a MaxNoInputs event?
The way Error Handlers are prioritized is the following, from highest to lowest priority:
Error Handler with predefined Types of event and Event Sources is executed primarily.
Error Handler with predefined Event Sources and empty Type of event is executed secondarily.
Error Handler with predefined Type of event and empty Event Sources is executed thirdly.
Configure Flow with miniApps as Event Source
If the Flow contains a miniApp or multiple ones, it can also be used as the Event Source.
Before using the Flow with miniApps as the Event Source, make sure it is a part of the Dialog Application.
Create a Flow that contains a miniApps or a few.
2. Open the Error Handlers drawer, click the + Add Handler button, select the targeted Flow from the Event Source dropdown menu.
It is possible to configure the Error Handler for the miniApp within the Flow regardless of the separate configurations of miniApp or within another Flow.
Drag and drop this Flow in the dropzone, and click Save. When any of the predefined errors appear, this Flow will be played.
Repeat Handlers function
The Repeat function of the Event Handlers feature provides the ability to repeat or start over the conversation by identifying specific phrases that indicate the caller wants to start over or go back. For example, if the caller says: “It’s not what I meant, I’d like to start over”, the NLU recognizes it as a phrase that triggers the Start Over functionality. When the Start Over is triggered, it clears all the predefined values in the scope of the Dialog, so they can be substituted with the new ones the next time the Dialog plays from the beginning.
If the Repeat Handler is not preconfigured, but the caller still says the trigger phrase, the Dialog will be started from the Intent miniApp. However, if the Intent miniApp hasn’t been used yet, the Dialog will be played from the first building block on the canvas.
To configure the Repeat function of Event Handlers feature, follow the next steps:
Click the Event Handlers tab on the right, switch to the Repeat tab and click the +Add Handler button.
2. Select the Event Type (the type of the event that triggers the usage of the Event Handler) and Event Source (the miniApps where the Event Handler will be used) from the dropdown. If Event Type is not specified, then the Repeat Event Handler will run for any Event Type. If the Event Source is not specified, it will run for all Event Sources.
3. Add and select any Drop Fields from the dropdown menu. These are the fields that will be cleared when any of the configured events take place.
If a miniApp or a Flow contains non-optional output fields and these fields are specified in the Drop Fields, a miniApp or a Flow will still repeat with the new values.
If the Flow with the Repeat Handlers is placed inside another Flow that has its own Repeat Handlers, the Repeat Handlers of the child Flow has the higher priority and will be executed.
OnDialogEnd Handlers function
The OnDialogEnd function of the Event Handlers is triggered once the dialog ends either on purpose or due to any error, and allows to pass data from a user via Intelli or WebService types of miniApps. For example, if an Orchestrator user wants to make an API call after the dialog ends and send back some reports, it is possible to use the OnDialogEnd function to make an API call to their own endpoints to collect data about the call at any point it can end. This function helps collect the preconfigured miniApps that gather call data in one block (for example, every single intent of the call) and, thus, to avoid the multiple usage of miniApps to serve particular task.
To configure OnDialogEnd function, follow the steps below:
Open the Event Handlers tab and switch to the DialogEnd function.
Click the +Add Handler button at the bottom to add a new function.
3. Configure the handler by setting the following values. Click Save when finished:
Ending Type - Select the type of call ending from the dropdown menu that will trigger the execution of the DialogEnd function:
TRANSFER - The call was transferred
SYSTEM ERROR - Any fatal error occurred in the system
NEAR_HUP - System Hang Up
FAR_HUP - Caller Hang Up
ERROR_SESSION_TIMEOUT - The call was terminated due to dialog’s inactive session timeout
TEARDOWN -The error sent by deepASR when the connection between deepASR and IVR is closed.
Related miniApp - drag and drop the miniApp of either WebService or Intelli type that will be executed after the dialog ends.
It is possible to add multiple DialogEnd functions that can handle different types of dialog endings (normal or due to error) each containing the corresponding miniApp, and they will be executed according to the order.
4. You can edit the name of the function or delete it by clicking the corresponding buttons.
It is possible to pass values between miniApps contained in DialogEnd function by configuring them.
5. Click the Options menu on the right of the selected miniApp.
6. In the opened window, configure the Input and Output fields to pass values to another miniApp. Click Save when finished.