Configure settings of miniApps and Flows

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.

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.

Input Fields

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.

Orchestrator passes the Input Field 1 to the miniApp where it will also be accessible under the same name.

Click the gear icon to extend the Input Field 1 view, and set the corresponding inputs for miniApp Field 1 and Orchestrator Field 1 variables.

If you want the field to be accessible inside the miniApp under a different name, change the miniApp Field to the field name you want.

The miniApp Field 1 automatically matches the name of Orchestrator Field 1.

Output fields

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.

Depending on the miniApp type (for example, the Announcement miniApp), the Output Fields can be preconfigured and read-only. However, when the Output Field is not predefined due to its configuration (for example, the Intent miniApp), you are able to select the preferred miniApp output.

Click the gear icon to extend the Output Field 1 view, and set the corresponding outputs for miniApp Field 1 and Orchestrator Field 1 variables. The Orchestrator Field 1 name coincides the miniApp Field 1 name automatically after the gear icon is triggered.

• 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.

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.

1. С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. 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.

Properties fields

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. Read the Fail Exit Reason document where 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:

1. С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:

1. Сreate a Dialog Application that consists of two connected miniApps.

2. Click the Settings button in the right upper corner of the selected miniApp to open the settings window.

3. In the settings window, click the + Add Input Field button.

4. Select the Input Field 1 from the dropdown menu in the Input Fields section.

5. The Input Field 1 variable corresponds the miniApp field with the same name and contains its data.

If you want to see the expanded view, click the gear icon. Now the Input Fields contain miniApp Field 1 and Orchestrator Field 1. The Orchestrator Field 1 automatically inherits the name of miniApp Field 1 so you don’t need to make it up.

You can add multiple Input Fields to drive the conversation depending on purposes. 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 Field is preconfigured in OCP miniApp and is selected automatically. Click the Save button to finish the process.

7. 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.

Configure Global Fields

It is possible for a user to set defined fields as global. Global fields are reusable in all miniApps and Flows within the Application, and are used without explicitly setting them as inputs or outputs over and over again in order to optimize interaction between Orchestrator and other services.

The built-in fields (for example, ANI, DNIS and so on) can not be set as global fields.

To set the global fields, proceed as follows:

1. Navigate to the Options menu icon onto the Application tab, click it to select the Global Fields label.

2. When clicked, create the global field. It is possible to create more than one global field. Click Save to finish.

3. Select a miniApp, click on the Options menu button and choose the global field from the list of the Input Fields.

Since the Flows are reusable within multiple Applications, the defined global fields can be fetched in any Application the Flow is used in.

Over-specification

During the dialog, miniApps obtain values from the conversation with a user, and pass values one by one as inputs to next miniApps in the logical order. However, it is also possible to optionally pass more than one value at the same time.

For example, the user wants to pay $100 from his checking account, and starts the dialog with the system. Normally, the system should first pull out the value from user’s response, and then proceed to ask the clarifying information using it for upcoming miniApps:

System: How can I help you?
User: I would like to make a payment.
System: So you want to make a payment, correct?
User: Yes, correct.
System: Great! How much would you like to pay?
User: I’d like to pay $100.
System: What account do you want to make a payment from?
User: From my checking account.
System: Ok, when do you want to make a payment?
User: Today please.
System: So, you would like to pay $100 from you checking account ending in 1234 effective today. Is that correct?

To optimize the conversation, the over-specification feature can be used.

Over-specification is a built-in feature of the system that allows understanding and handling of information that is provided by the caller before being explicitly asked. This information can be passed as fields' values after successful validation and confirmation processes configured within the miniApp. Thus, the system doesn’t ask multiple times for the additional data, but receives it all from a single request and fills it in the fields of the upcoming miniApps automatically.

If the first in line miniApp has optional fields, that are mandatory for the next in turn miniApp, these fields will be validated and confirmed without re-asking their values.
Note that the optional fields from the first miniApp should have exactly the same names as in the later miniApps they are used in.

Once the over-specification is used, and the validation and confirmation of the miniApp are passed, the dialog would look as following:

System: How can I help you

User: I would like to pay $100 from my checking account today.

System: So, you would like to pay $100 from you checking account ending in 1234 effective today. Is that correct?

In this example, the user passed not only the intent, but also the amount to be paid, when and from which account. Thus, the system shouldn't re-ask the user for the same information but, instead, it should go directly to confirmation and validation.

To apply correctly the over-specification, do the following:

1. Configure validation and confirmation logic in the miniApps board.

2. Set up the dialog flow to receive these fields as optional entities.

miniApp	Input and Output Fields Configurations