Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

Overview

This article walks through an example of using a Rule Set to build branching from one skill to two other skills. In the example, a user asks for access to an application; the triggered skill will prompt them asking which application they need to access. Based on their response, a Rule Set will take the user to one of two new skills designed specifically for giving them access to that application.

Here is the conversation flow shown in the Bot Testing widget in the Bot Builder interface. It shows the different scenarios when a user selects Salesforce, Workday or SAP.

Components of the Conversation

To build this Application Access conversation, there are several components that were created.

Attributes

Three attributes were created first. It is a best practice to create global attributes first before building your skills. Drawing out the flow and prompts on paper or in a diagramming tool is often useful. The three attributes are:

Application List - This is a text type attribute with NLP Value Extraction. It will prompt the user to ask if they need access to Salesforce, SAP or Workday. See the details in the following screenshot.

Sales Account Type - This is another text type attribute with NLP Value Extraction. It will prompt the user to select the type of Salesforce account they will need.

Workday Role - The last attribute is also a text type attribute with NLP Value Extraction. NLP Extraction is useful as it allows tagging phrases and skipping prompts which makes the user experience much better. It will prompt the user to select the type of Workday access they require.

Skills

After the attributes are created, it is time to build the skills. While the skills can be created in any order, it is best to start from the bottom of your flow and move up. Essentially create the child skills first and then build the parent skill last. This is preferred because the Rule Set requires that the skill you are branching to, exists.

For this example, there are three skills to create.

Salesforce Application Request - First, create the Salesforce skill. This will be triggered by the top-level Application Access Request. In this skill the user will be prompted with the Sales Account Type attribute prompt and then receive a simple fulfillment message that their request is being worked on. In a real skill, an integration is required. In the following screenshot, the user's input is shown in the fulfillment message with the variable format @ {global.attributeidentifier} .

Workday Access Request - Next, create the other child skill. The Workday skill will be triggered by the Application Access Request skill when the user selects Workday. The Workday skill has a single prompt asking the user for the type of Workday account they require. The skill also uses a fulfillment message with an attribute. See the following screenshot. 

Application Access Request - The last skill to create is the Application Access Request. This is the top-level or parent skill. In many skill branching scenarios, you will want to direct users to a generic skill to gather more information and then direct them to a specific skill. Like the other two skills, there is a single attribute with a prompt asking the user to select the application they need to access. After that attribute, there is a Rule Set. Continue to the next section for a detailed walkthrough of creating the rules for this example.

Defining a Rule Set

For the basics on Rule Sets see Rule Set Overview.

This Rule Set's goal is to evaluate what the user entered in the Application List attribute prompt and take the user to the skill for that value. There are two rules in the Rule Set and a Fallback Rule:

  1. Salesforce: This is represented as @{global.presal_application_list} equals Salesforce. The attribute identifier is always used with global. or local. as the prefix depending on if it is a global or local attribute. If this Rule evaluates to true, then the Execute value is set to Salesforce Application Request, the name of the Salesforce skill that was previously created.
  2. Workday: This Rule is almost exactly the same as the Salesforce rule except the condition is @{global.presal_application_list} equals Workday and the Execute value is set to Workday Access Request.
  3. Fallback Rule: The Fallback Rule is used when none of the rules evaluate to True. This case is used when the user selects SAP from the Application List prompt. The Execute value here is Continue, which means the skill will continue processing through the Conversation Flow and Fulfillment. In the Application Access Request, a fulfillment message is shown to the user with the input.

In this example, the Set and Clear Attributes section was not used. This section is useful if you want to set Global attributes before branching to another skill or even setting a value local or global value for the existing skill.

  • No labels