About this guide
This document provides a detailed description of the Orchestrator web application.
Orchestrator allows users to create a logically completed conversation that represents a dialog between the application and the caller by combining the existing OCP miniApps® and other building blocks.
Orchestrator is a web application, part of the Omilia Cloud Platform® (OCP®), which allows users to combine existing miniApps created in OCP miniApps® web application to build and run a complete Dialog Application that can be further connected to a phone number or a chatbot to maintain a conversation.
The Dialog Application is a sequence of combined miniApps and other Orchestrator building blocks for running a conversation according to the logic the user defines.
OCP miniApps® are zero-coding, zero-maintenance, instantly deployable, and configurable natural language dialog components that handle a single task, such as soliciting a US address or credit card number, or even negotiating an appointment.
For an easy and convenient experience, Orchestrator allows to drag and drop conversational building blocks that contain conversation intelligence onto a canvas and connect them by stretching arrows from one to another that correspond to the logical order of conversation.
This section contains the basics required to build and deploy a simple Dialog Application. The Dialog Application is a sequence of combined miniApps and other building blocks (optional) for running a conversation according to the logic predefined.
The progress is saved automatically at any point of the development.
Get familiar with Orchestrator board by following these steps:
To enter the Orchestrator, log into OCP web service or sign up to create an account.
Click the Console button in the right upper corner. This is the unified entry point for managing all OCP services.
3. Navigate to Console → Orchestrator.
4. You will be forwarded to the landing page of Orchestrator where it is possible to:
select one of the applications to work on:
or start with creating a new application by clicking the +Create button:
5. If it is the first use of the Orchestrator, it is prompted to create a new application. Fill in the fields of the Create new application form that pops up once you log in.
5. Application Name: enter a name for your new Dialog Application.
6. Group: select a group from the available groups of the dropdown list to which the Dialog Application belongs. The Dialog application is accessible from other group members.
7. Click Save to be directed to the Orchestrator board.
The left sidebar contains the building blocks: miniApps, Flows and Dialog Controls, which are the building blocks of the Dialog Application.
The central part displays the canvas where you can drag and drop building blocks, connect them with arrows and create a Dialog Application.
In the upper panel there is a tab of the current Dialog Application. The dot on the left of the current Dialog Application’s name is grey if the application is not deployed and turns green if the application is deployed.
In the upper right, there is a dropdown menu of the available Dialog Applications that you can switch between, and the Deploy button to deploy your Dialog Application at any time for testing or production use.
Click the Chat icon in the lower right corner to open the Orchestrator chat and simulate a deployed Dialog Application.
The Event Handlers drawer on the right side allows the configuration of possible conversation scenarios if an error occurs.
Create a Dialog Application
To create a simple Dialog Application, follow the steps below:
Navigate to the miniApps panel on the left sidebar and click the Manage button to be directed to OCP miniApps® web application and create a new miniApp. For more information, check out How to manage your miniApps®.
2. Create a miniApp of any particular type. Read on about the types of miniApps on Types of OCP miniApps®.
3. Once created in the miniApps web application, it is automatically listed in the miniApps tab of the Orchestrator.
4. To apply a miniApp in the Dialog Application, drag and drop it onto the canvas.
5. A basic Dialog Application is built. This Dialog Application that contains this particular miniApp will be played when receiving a call or talking to a chatbot.
6. Click the Deploy button to run the Dialog Application. The Dialog Application is ready to accept calls and have sessions with a chatbot.
7. A message appears if the deployment was completed successfully.
8. To test the Dialog Application, click the Chat icon in the right lower to open the Orchestrator Chat. The Orchestrator Chat simulates the conversation using the deployed Dialog Application on the canvas.
Delete a Dialog Application
To permanently delete a Dialog Application, do the following:
Select the Dialog Application you want to delete and click the Options menu button on the Dialog Application panel.
2. Click on the Delete option to open the confirmation window.
3. In the confirmation window, type CONFIRM DELETE in the corresponding field, and click the Delete button to finish.
Once deleted, the Dialog Application can not be restored!
Orchestrator keyboard functions
Delete a building block (miniApp, Flow, Condition, Transfer)
Click on the building block you want to delete to select it.
Press <Fn> + <Backspace> or the <X> button on the keyboard.
Delete a connection between building blocks
Click on the connection line you want to delete to select it.
Press <Fn> + <Backspace> or <X> button on the keyboard.
Copy and paste a single building block.
Click on a single building block you want to copy.
Press <cmd/ctrl> + <c> to copy it.
Hover the cursor onto the canvas and press <cmd/ctrl> + <v> to paste it.
To select multiple blocks, hold Shift and then click on each one of them.
Orchestrate an advanced Dialog Application
This section describes advanced features of the Orchestrator:
How to build a more complex Dialog Application with at least two building blocks.
How to configure them by passing values to miniApps.
Read the Getting Started section before going through this one. You should be familiar with Orchestrator controls and able to create a simple Dialog Application that uses one miniApp onto the canvas.
Connect building blocks
To connect building blocks, follow the steps below:
Navigate to the miniApps panel at the left sidebar, and click the Manage button to create a miniApp in OCP miniApps® web application. Configure this miniApp according to purpose whether it is a question trying to get an intent or information out of the caller, an announcement, or anything else. Once created, it is listed in the miniApps section.
2. Select the created miniApp and drag and drop it onto the canvas.
3. Hover the cursor over a building block on the canvas. When the dots appear, click on the building block and hold. Drag the connection line to the building block you want to connect to (a second miniApp in this case) and release the button to connect them.
miniApps and Flows values configuration
miniApps help convey information to the callers and receive an answer from them. Callers' information is passed to the following miniApps in the Dialog Application by configuring them accordingly.
To make settings configuration in Orchestrator, it is recommended to be familiar with miniApps configuration.
Each miniApp or Flow building block in the Orchestrator has input and output fields for the receiving and the outgoing information.
To configure these fields, click the Settings icon in the right upper corner of a selected miniApp or another building block to open the settings window.
The output field of a miniApp or other building block depends on the miniApp and can be used in the input field of any of the following miniApp or Flow building blocks to drive the conversation accordingly.
The Input fields contain information that can drive the conversation. It can either be information provided from the caller’s data (phone number, area calling from), or information provided to the caller during the conversation and extracted as output from another miniApp.
The type of input data depends on the type of miniApp and can be set during miniApp configuration.
The Orchestrator contains data of the miniApp that will be passed to a caller in specific pair of parameters - Input name and Field name.
The parameter of the miniApp Field 1 in Orchestrator equals the value of the same parameter of miniApp which is configured in the OCP miniApps® web application, whereas the data of this value that is actually passed to a caller is stored in the Orchestrator Field 1.
OCP miniApps® return values based on the responses of the callers and what information miniApps are configured to extract from them. The Output Fields contain the information extracted from the caller while they are talking to the miniApp the following way:
The miniApp Field1 is a parameter in the Orchestrator that equals the value of the same parameter configured in the miniApp to contain another parameter with the caller’s response.
The Orchestrator Field1 stores the value with the actual caller’s response.
Change the Field name name of Output Fields to something that makes sense to you and is relative to the expected output (for example, cardNumber, accountID). Do not change the Value name of Intent type miniApps.
Multiple Output fields
It is possible to add multiple Output Fields to pass extra information from the caller. For example, if instead of “I want to make a payment” the caller says “I want to put 20$ on my credit card”, this information can be stored by adding some extra Output Fields. This information can be recognized by NLU and passed as an NLU entity by adding the entity name as an Output Field.
Also, these extra Output Fields can be optional, so even if you decide not to select this field, the miniApp will still receive all the necessary information.
Сlick the Options menu on the right upper of the selected miniApp.
2. In the opened window, click the + Add output Field to add more items.
3. Drag the toggle button next to the output field to make it optional. Also, you can remove the optional field by clicking the Trash can icon.
This approach is valid for all the miniApp types except Intelli and Web Service, since these types of miniApps do not use NLU.
Multiple Output fields in Intelli and Web Service miniApps
Adding multiple output fields in the Intelli and Web Service miniApps is also applicable. However, if any of these miniApps end, while multiple fields are defined without providing any values, the Dialog Application will still run.
The Properties fields store the extra information of the miniApps configuration which overwrites some of the preconfigured or default miniApp settings directly in Orchestrator. For example, you can reconfigure the error threshold in a certain miniApp per one usage during the Dialog, whereas this threshold will still be the same (default) in any other cases this miniApp plays.
These Properties are collected in the list of the specific fields that are available for being reconfigured in a certain miniApp. Here you can find more information about the available specific fields. Once Properties and their Values are reconfigured in Orchestrator, the new parameters are passed to the miniApp. Each Property type can be reconfigured only once in a certain miniApp.
This functionality is available for all the miniApp types, the Anything Else? building blocks, but not for the Flows.
To overwrite the miniApp configuration, follow the next steps:
Сlick the Options menu on the right upper of the selected miniApp.
2. Switch to the Properties tab and click the +Add button.
3. Select the specific field you want to reconfigure in the miniApp from the Property 1 field. For example, choose the Continuous agent request field from the dropdown menu, so it will be reconfigured in the miniApp.
4. Specify the Value 1 field. For example, enter 3 to overwrite the default configurations, so the new value will be used for the selected Property 1 field when the miniApp plays at this step of the Dialog.
5. Click Save when finished.
Configure Settings of miniApps fields
miniApp and other building blocks have configurable settings for Input and Output fields. To successfully drive a conversation, the Output field of the originating miniApp affects the Input field of the next ones.
To configure the settings of a miniApp building block, follow the steps:
Сreate a Dialog Application that consists of two connected miniApps
Click the Settings button in the right upper corner of the selected miniApp to open the settings window.
In the settings window, click the + Add Input Field button.
4. Select the extValue1 from the Input name 1 dropdown menu in the Input Fields section.
5. Define the variable for the Field name 1 field from the dropdown list.
When more building blocks are added and more miniApps are connected, more information is elicited from callers and the dropdown list of possible Input Field values grows with the Output Fields value of the previous building blocks.
6. The Output name field is preconfigured in OCP miniApp and is selected automatically, whereas the Field name contains the value of information retrieved from the caller, and can be modified.
7. Click the Save button to finish the process.
8. Select another miniApp, click the Settings button in the right upper corner of the miniApp and configure it so that the output from the previous miniApp that contains the caller’s response can now be used as a value of the Input fields. Click Save when finished.
Now that the miniApps are configured, they can pass information to the callers, receive and read their answer, process it to be further used in the next building blocks, and create a conversation that you can test in an Orchestrator Chat.
The Condition is a building block that allows you to guide the conversation depending on the caller’s answer. You can configure it to cover multiple scenarios of the conversation.
For example, there is a miniApp in the Dialog Application that asks the caller: “Do you want to know more about our service?”. The caller may answer “yes” or “no”. The Condition building block allows to drive this conversation depending on the caller’s answers by creating multiple scenarios.
Follow these steps to create a Condition:
Navigate to the Dialog Control panel on the left, drag and drop the Condition building block onto canvas and connect it with the miniApp just like you do with any building block.
2. Select a miniApp or create one by clicking the Manage button and drag and drop it onto the canvas.
3. Connect the miniApp with the Condition just like any other building block. The condition setting window pops up.
4. Click the + Add Condition button.
5. Select the Field 1 value from the dropdown menu: it contains the value of the Ouput fields of the previous miniApps
6. Provide the Value 1: it is the name of the field that contains the value for the caller’s answer in the miniApp. It is possible to select any value for the Value 1 field by entering a * symbol. It means that when * is entered, the predefined condition scenario can use any possible value except for the empty one.
7. Click Save when finished.
It is also possible to create a scenario where the value of the Field 1 doesn’t equal the value of the Value 1 field.
To do this, click the equals symbol in the Condition Settings area and select the inequality sign.
Configure Default Condition
It is also possible to branch the scenarios of the Dialog Application by using the default condition. If created, the Dialog Application will use this condition in all the possible cases that are not configured in this condition.
To create a default condition, follow the steps below:
Select a miniApp from the list, drag and drop it onto the canvas, and connect with the Condition block with a line.
2. Once connected, click Save so the default condition will be created automatically.
For example, when the default condition is applied, if the caller answers "no" to the yes-no question of the ProvideExtraInformation miniApp while running the conversation, then the default condition that brings to the AskIntent miniApp will be played.
Manage multiple Conditions
You can use multiple Conditions when there are more than one conditions that you need to check simultaneously, or you have various intents to select. You can select two conditions at the same time, or you can provide a choice of conditions with the use of the AND and OR scenarios.
To set multiple Conditions follow the steps:
Create a scenario where the caller answers Yes and wants to change pin number.
Navigate to the Dialog Application, and click the label of the condition to start editing it.
2. Click the + Add Condition button.
3. Select AND radio button if you want to apply another condition. For example, if the caller answers “yes” AND has an intent to change the PIN number. In this case, you need to select the Field 2 value from the dropdown list of the available fields and assign a variable to the Value 2 field, which, at this point, is changePinNumber value. Click Save when finished.
The Dialog Application will be the following: if the caller provides the extra information and, at the same time, the intent is to change their PIN code, then the ExtraInfoAnnouncement miniApp will be played next.
4. Click Save when finished.
Create the scenario where the caller answers “no” OR wants to check the balance.
Navigate to the Dialog Application, and click the label of the condition to start editing it.
2. Click the + Add Condition button.
3. Click the OR radio button, then navigate to the Field 2 and select Intent from the dropdown list, and assign balanceCheck to the Value 2.
4. Click Save when finished.
Therefore, if the caller answers “no” and wants to check the balance, the AskIntent miniApp will be played.
Configure LastFailReason Field
Configuring the LastFailReason allows to specify the last error that occurred but does not end the conversation. If the defined error occurs, it doesn’t trigger any Error Handlers or stops the Dialog Application, but plays the next miniApp or another building block in a row. It allows keeping a conversation running instead of just being finished even though the error happened.
Since it is a part of the Condition feature, the multiple conditions can be executed alongside with defining the LastFailReason.
For example, if a caller doesn’t have the information asked by the miniApp (which is one of the error types that can end a conversation), the conversation will be running if this error was specified as the LastFailReason. To read more about the error types, navigate here.
To configure the LastFailReason, do the following:
Select a miniApp from the list, drag and drop it onto the canvas, and connect with the Condition block with a line.
Once connected, click the + Add Condition button.
3. Select the LastFailReason from the Field 1 dropdown menu, and specify the error that can happen in a miniApp, but won’t stop a conversation from running or trigger the Error Handler.
The LastFailReason can be used as an input field in the next miniApp, so it could allow to specify the cause of this error.
The Anything Else? building block allows to prevent a conversation from ending by repeating the selected Intent miniApp. It is possible due to configuring the Anything Else? building block that plays the predefined miniApp and contains re-ask prompts that can ask a caller whether there is anything else to help them with. This feature is available only in the context of the Intent type of the miniApp.
Configure Re-ask Prompts
Before using the Anything Else? building block, navigate to the OCP miniApps and configure the Re-ask Promtps that the caller receives when the Anything Else? plays. This re-ask prompt will be used in the Anything Else? building block as the Re-ask Prompt Index.
Select the miniApps tab from the left sidebar, and click Manage.
2. Select the miniApp of the Intent type from the list, click to configure it to be further used in the Anything Else? block.
3. Navigate to Prompt Indexes in the Re-ask Prompts tab and configure the available prompts by changing content or adding values respectively. Click Save Changes when finished.
Enable Anything Else? block
Navigate back to Orchestrator and proceed with enabling Anything Else?:
Select the Anything Else? building block from the Dialog Control panel on the left sidebar.
2. Drag and drop it onto the canvas to connect with other building blocks to run the conversation.
3. Click the Settings icon in the right upper corner of the Anything Else? block and configure the following. Click Save when finished.
Intent miniApp: choose a miniApp from the dropdown list that contains all the Intent type miniApp that were already used in the Dialog Application.
Re-ask prompt: select the re-ask prompt index of the miniApp that has been already configured in the OCP miniApps®.
Input Fields: configure the Input Fields as in any other miniApp.
Output Fields: configure the Output Fields as in any other miniApp.
Once the Anything Else? building block is enabled and the Dialog Application runs to it, the miniApp defined in the Anything Else? block will be played and the configured data with the Re-ask Prompt will be passed to a caller.
Reset on Intent Change
The Reset on Intent change flag allows re-asking a piece of information if the caller provides a second intent. If the feature is enabled, all the data previously contained in outputs is erased, and, since the conversation continues from the selected miniApp, is substituted by the data containing new intent from a caller.
The Reset on Intent Change can only be applicable in the Intent miniApp if the Anything Else? building block has already been used.
To enable the feature, follow the steps:
Select the miniApp that you want to be repeated if the caller’s intent changes and click the Settings button in the right upper corner of the miniApp to configure.
Check the Reset on Intent change box to enable the feature.
Deploy a Dialog Application
When the Dialog Application is completed and ready to be tested, or used to serve real calls, it can be deployed. Deploy means that your Dialog Application can be tested in the Orchestrator Chat to simulate the conversation between a real caller and a chatbot.
Follow these steps to deploy a Dialog Application:
Click the Deploy button in the right upper corner.
2. If the deployment is successful, you receive the following message in the right upper corner.
Test a Dialog Application
A chat bot is available to test a deployed Dialog Application.
To test a Dialog application, follow the step below.
Click the Chat icon in the lower right corner to open the Orchestrator Chat.
In the Orchestrator Chat window, you can have a conversation that is using the configured miniApps and it is displayed in the order that it was configured.
3. Add your input to the chat to check if the conversation evolves as desired.
Build a Flow
A Flow is a reusable building block that can contain miniApps, Conditions, Transfers, and even other Flows grouped according to the predefined logic same as a Dialog Application. As a Dialog Application scenario grows and has more building blocks, it is recommended to organize parts of it logically grouped and saved, or to have it prepared to use while building a different Dialog Application. These cases can be covered with the Flow building block.
Flows can be reused in multiple Dialog Applications, if these Dialog Applications belong to the same group.
Flows can be used to create complicated flow logic condensed in a building block that can be reused in a Dialog Application or used throughout different Dialog Applications and save time.
To build a Flow, follow the steps below:
Navigate to the Flows panel on the left and click the + Add button.
2. Fill in the fields in the modal window and click Save when finished:
Enter a Flow Name. For example, Authenticate, for a Flow that is used to authenticate callers.
Enter the Input Fields to assign a value containing data that will be passed to a caller to the Flow.
Output Fields: assign the value that is returned as the caller’s answer.
Select a Group from the available list. The Flow will be available to the group members.
3. Once created, the Flow is listed in the Flows panel.
4. Click the Flow, so it will be opened in a separate tab for a further configuration.
5. Select a miniApp from the miniApps list and drag and drop it into the canvas. Note that now you are working inside the Flow.
6. Click the Settings button in the right upper corner of the miniApp to configure it.
7. Fill in the fields in the settings window and click Save.
Input fields: assign an external value to the Flow.
Output fields: assign the value that is returned as the caller’s answer.
7. Select or create a second miniApp just like you did in the Getting Started section. Note that now you work inside the Flow.
8. Connect two miniApps by dragging a line between them.
9. Click the Settings icon in the right upper corner of the second miniApp to configure it.
10. Click the + Add Input Field first and then proceed to filling in the fields like you for any other miniApp, click Save when finished.
This Flow contains two configured miniApps that are connected logically by passing values to one another representing a completed piece of a Dialog Application. Since the Flow is a reusable building block, this particular Flow can be used in multiple cases in the Dialog Application and provide the preconfigured data it already contains, so it is not required to configure it from the beginning.
It is possible to easily and quickly edit a Flow's Input and Output. To do that, follow the steps below.
Navigate to the left sidebar with Flows, click the Options button in the right upper corner and click Edit.
2. In the newly-opened form, edit the Input and Output fields.
The values of Input and Output fields will be available in other building blocks of the Dialog Application.
Optional output fields
It is possible to add optional output fields to the Flow. These optional output fields can be selected from the list of the preconfigured Flow outputs. However, if the output value is not provided, the Flow will still continue.
To configure optional output fields, proceed as follows:
Navigate to the left sidebar with Flows, click the Options button in the right upper corner, click Edit and add multiple output fields.
2. Place the Flow onto the canvas, click the Settings button in the right upper corner, and click the toggle button to select optional output fields. Note that you should have at least one non-optional output.
Delete a Flow
To permanently delete a Flow, do the following:
Select a Flow from the list on the left and click the Options menu icon in the right upper corner of the Flow and click Delete.
It is not possible to delete a Flow if it’s already placed on canvas and is used as part of a Dialog Application. Remove a Flow from canvas to delete it.
A Transfer is a building block that allows the deferral of the conversation to a real agent, a chatbot, or any other conversational system. The Transfer saves all the data of the conversation to that point, so the agent can access it and the caller doesn’t need to explain the request from the beginning.
As the conversation continues, the caller faces the necessity to reach out to a real agent, for example, to a bank’s call center so a Transfer must be added to the flow.
To add a Transfer, follow the steps below:
Open the Dialog Control panel on the left and click the + Add button.
2. Fill in the fields in the modal window of the Transfer settings:
Enter a Name: the name of the transfer
Define a Target: the recipient’s data. For example, the agent’s phone number
3. Click the Save button to finish. Once saved, the Transfer will be available in the list of the Dialog Control panel.
4. Select the Transfer from the Dialog Control list and drag and drop it onto the canvas.
5. Connect the Condition block with the Transfer by dragging a line between them.
As a result, if the miniApp asks the caller whether they want to know more information about the service, and their answer is “no”, then the Dialog Application channels to the Transfer building block, which, in turn, redirects a caller to a real agent.
6. To delete or edit a Transfer, navigate to the Dialog Control panel, select a Transfer and click the Options menu button.
Configure Incoming Attached Data
When a caller contacts the call center and transfers some information during a conversation, the call center can transfer this information to Orchestrator. Orchestrator can configure this data to be used while building the dialog application as a field in building blocks.
To configure the Incoming Attached Data you first need a Dialog Application and follow the steps below:
Navigate to the tab with the selected Dialog Application, and click the Settings button on the right.
2. Fill in the following fields, and click Save when finished:
Incoming Field name 1 - stores data received from the call center (the name of the field is provided by the call center).
Local Dialog Field 1 - enter the name of the field that stores the data and can be later used in the Dialog Application. It is possible to add multiple Incoming Attached Data fields by clicking the + Add Incoming Field.
3. To use the field that stores the Incoming Attached Data, click the Settings button on any miniApp building block to open the settings.
4. Navigate to the Input Fields, open the dropdown menu of the Value 1 field, and select the field of the Incoming Attached Data.
Once configured, the field representing the Incoming Attached Data is available for building blocks of all types.
The Set Field is a building block that contains the configurable data from the caller (a field and a value) that can be transferred to other miniApps or building blocks and channel the conversation. The value of the Set Field building block can substitute the value of a previously used miniApp or building block. For example, the user can configure the Set Field building block by creating a field or choosing the available one from the list, and providing a value that contains the information from the caller. This allows to use the data from the Set Field building block instead of configuring and using complex miniApps or Flows.
To add and configure a Set Field building block, follow the steps:
Choose the Set Field building block from the Dialog Control panel, drag and drop it onto canvas and connect with another building block, for example, the ExtraInfoAnnouncement miniApp.
2. Click the Settings icon in the right upper corner of the Set Field building block to configure it.
3. Click + Add Input Field button first.
4. Type a field name to create a new one, or select one from the dropdown menu of the available ones; these are the fields previously used in the conversation.
5. Enter a value that can be received from the caller, and click Save when finished.
If the Value field is empty (undefined), the previous miniApp or any other building block will be played again. For example, if Intent is selected as a field, and cardNumber is selected as a value in the Set Field building block, cardNumber will be used instead of the value from the ExtraInfoAnnouncement miniApp.
It is possible to add a counter-type field for the Set Field block (covers the function of the Intelli miniApp). For example, the counter value can be passed as an input to other building blocks, so it can track how many times an error has occurred during the course of a dialog and take special actions once a specific threshold has been exceeded.
To add a counter, select the plus equals sign from the dropdown so it increments a value of the Value field. In this case, the Value field can contain any positive or negative number.
The Log building block helps you gather the detailed information about the Dialog Application or a Flow.
There are two approaches that allow to gather different types of information:
Defining Fail Reason: The Fail Reason contains the name of the cause why the Dialog Application or a Flow might has failed, has succeeded or has been executed, and allows to log this status.
Selecting Key-Value pair: Key-Value pair of data contains the gathered information during the dialog, so it could be further tracked on the Analytics.
Further, you can check the collected information or the status on the Analytics for statistical purposes. For example, you can log the status as failed for the particular Dialog Application or a Flow, although the Dialog Application or a Flow doesn’t fail.
It is possible to either add a custom fail reason, some key-value pairs, or both at the same time.
It is possible to use the names of the previously used fields and values to log them precisely, or it can be any other text to substitute the field or value.
If the Log building block is used twice in a row, only the second one will be applied.
To apply the Log building block, do the following:
Choose the Log building block from the Dialog Control panel on the left, drag and drop it onto canvas, and connect with another building block.
2. Click the Settings button in the right upper corner of the Log building block to configure it.
3. Define the Fail Reason, or click + Add Input Field button to define a Key-Value pair (it is possible to add multiple pairs of data by clicking the + Add more button). Click Save to finish.
Statistics of Flow Status
Since the Logging block allows to define the status of the Flow, it is possible to further track it for statistics that provides you the detailed information on successful or failed Flows, and the additional information, such as the reason the for Flow failure.
To check the statistics of the Flow status, navigate to the Console, and select the Insights tab.
Substitute Field’s Value
For a list of particular building blocks, such as Conditions, Set Field block, Logging block and Transfer, it is possible to substitute the name of the field by the value itself, so the value can be used dynamically. The feature is available by adding the # symbol into the value field, and selecting the value from the dropdown list, so only the available fields can be used.
For example, if you want to log the value of the CardNumber in the Logging building block, proceed as follows:
Click the Settings button in upper right of the Logging block.
2. In the opened window, click the + Add button to proceed.
3. Enter any name in the Logging Key 1 field, and type the # symbol in the Value to log 1 field. Select the CardNumber as a value from the prompted list. In this case, the literal value will be used.
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 here.
Configure default Error Handler
1. 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 it 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 everything is successful, 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 MaxNoInputsand 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:
1. Error Handler with predefined Types of event and Event Sources is executed primarily
2. Error Handler with predefined Event Sources and empty Type of event is executed secondarily. 3. 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.
3. 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.