10 The Dialog Flow Definition

The dialog flow definition is the model for the conversation itself, one that lets you choreograph the interaction between a skill and its users.

Using the Skill Builder, you define the framework of the user-skill exchange in OBotML, Digital Assistant’s own implementation of YAML. This is a simple markup language, one that lets you describe a dialog both in terms of what your bot says and what it does.

The Dialog Flow Structure

Your OBotML definition is divided into three main parts: context, defaultTransitions, and states. You define the variables that are available across the session within the context node. The definition of the flow itself is described in the states section. The dialog flow is laid out as follows:
main: true
name: "HelloKids"
context:
  variables:
    variable1: "entity1"
    variable2: "error"
...
States      
    state1:
      component: "a custom or built-in component" 
      properties: 
        property1: "component-specific property value"
        property2: "component-specific property value"
      transitions:
        actions:
          action1: "value1"
          action2: "value2"
    state2:
      component: "a custom or built-in component" 
      properties: 
        property1: "component-specific property value"
        property2: "component-specific property value"
      transitions:
        actions:
          action1: "value1"
          action2: "value2"
...

The context Node

The variables that you define within the context node can be primitive types like int, string, boolean, double, or float. You can define a variable as a map, which is a JSON object, or you can use variables to describe error handling.

As illustrated by the following snippet from the PizzaBot dialog flow definition, you can name variables for built-in or custom entities (which in this case, are the PizzaSize and PizzaCrust variables). Along with built-in entities and the custom entities, you can also declare a variable for the nlpresult entity, which holds the intent that's resolved from the user input. These variables are scoped to the entire flow. How Do I Write Dialog Flows in OBotML? tells you how to assemble the different parts of the dialog flow. You can also scope user variable values to enable your bot to recognize the user and persist user preferences after the first conversation. User-Scoped Variables describes these variables.
metadata:
platformVersion: "1.1"
main: true
name: "PizzaBot"
context:
  variables:
    size: "PizzaSize"
    type: "PizzaType"
    crust: "PizzaCrust"
    iResult: "nlpresult"

The defaultTransitions Node

Use the defaultTransitions node to define routing that allows your skill bot to gracefully handle unexpected user actions. In particular, you can use it to enable your skill bot to react appropriately when a user taps an option in a previous reply instead of one of the options presented in the bot's current (and more appropriate) reply. As shown by NONE action in the following snippet, you can configure this transition to route to a state that handles all of the unexpected actions.
defaultTransitions:
  error: "DefaultErrorHandler"
  actions:
    unexpectedAction: "HandleUnexpectedAction"
...
HandleUnexpectedAction:
  component: System.Switch
  properties:
   variable: user.botsUnexpectedAction
   values:
     - pizza
     - pasta
     - order
  transitions:
    actions:
      NONE: "ActionNoLongerAvailable"
      pizza: "OrderPizza"
      pasta: "OrderPasta"
      order: "AskPizzaSize"

The states Node

You define each bit of dialog and its related operations as a sequence of transitory states, which manage the logic within the dialog flow. To cue the action, each state node within your OBotML definition names a component along with component–specific properties and transitions that trigger the next state. The PizzaBot includes a sequence of state nodes that verify a customer’s age. These states include components that take the user-supplied integer value, check it, and then output a text string as appropriate. To start off the process, the askage state’s component requests the user input then moves on to the checkAge state, whose AgeChecker component validates the user input. Here, the dialog is at a juncture: its transitions key defines the block or allow states. If the allow state is triggered, then the user can continue on. The subsequent state definitions will track the user input to preserve the user’s context until she completes her order. If the user input causes the AgeChecker component to trigger the block action, however, then conversation ends for the under-age user because the dialog transitions to the underage state.
metadata:
platformVersion: "1.1"
main: true
name: "PizzaBot"
context:
  variables:
    size: "PizzaSize"
    type: "PizzaType"
    crust: "PizzaCrust"
    cheese: "CheeseType"
    iResult: "nlpresult"
...

  askage:
    component: "System.Output"
    properties:
      text: "How old are you?"
    transitions: {}
  checkage:
    component: "AgeChecker"
    properties:
      minAge: 18
    transitions:
      actions:
        allow: "crust"
        block: "underage"
  crust:
    component: "System.List"
    properties:
      options: "Thick,Thin,Stuffed,Pan"
      prompt: "What crust do you want for your Pizza?"
      variable: "crust"
    transitions: {}
...
    underage:
    component: "System.Output"
    properties:
      text: "You are too young to order a pizza"
    transitions:
      return: "underage"

How Do I Write Dialog Flows in OBotML?

OBotML uses a simple syntax for setting variables and defining states. Because it’s a variant of YAML, keep the YAML spacing conventions in mind when you define the dialog flow. You don’t need to start from scratch. Instead, you can use the Echo bot’s dialog flow definition as a basic template.
Along with the metadata definition at the top of the dialog, the Echo bot already has the context and states nodes, so you can just delete the existing boilerplate and add your own content. To help you build state definitions that are syntactically sound, use the component templates in the Add Components menu. See Dialog Flow Syntax for tips on setting variables and defining states.

Important:

Click Validate and check the logger widow (This is an image of the debug icon.) as you write your dialog flow.

Dialog Flow Syntax

How Do I? Use this
Set variables that persist the context across the entire dialog flow?
Within the context node, use the following syntax: variablename: "variableType" For example:
main: true
name: "FinancialBotMainFlow"
context:
  variables:
    accountType: "AccountType"
    txnType: "TransactionType"
    txnSelector: "TransactionSelector"
    toAccount: "ToAccount"
    spendingCategory: "TrackSpendingCategory"
    paymentAmount: "string"

You can define variables as entities (like AccountType and ToAccount) and as primitives (paymentAmount: “string”).

Define an error handler for your bot?
Define the defaultTransitions node. For example:
context:
  variables:
    iresult: "nlpresult"
defaultTransitions:
  next: "ImplicitTransitionDetected"
  error: "MyErrorState"
  actions:
    unexpectedAction: "HandleUnexpectedAction"

See Configuring the Dialog Flow for Unexpected Actions.

Define a variable that holds the value for the resolved intent?
Within the context node, define a variable that names the nlpresult entity. As its name implies ("nlp" stands for Natural Language Processing), this entity extracts the intent resolved by the Intent Engine. Nearly all of the reference bots declare nlpresult variables. For example:
main: true
name: "FinancialBotMainFlow"
context:
  variables:
    iResult: "nlpresult"
Control the dialog flow based on the user input?

Typically (though not always), you’d define an nlpresult variable property for the System.Intent component that returns the result from the Intent Engine. See System.Intent.

In the following snippet from the FinancialBot dialog flow, the System.Intent component instructs the Dialog Engine to proceed based on the value returned by its nlpresult variable (iResult). As described in The Dialog Flow Structure, you can declare an nlpresult variable in the flow’s context node to hold the resolved intent (iResult:”nlpresult” ). The potential outcome, defined by the states named in the actions node, is also predicated on Confidence threshold property. You can set this optional property against the probabilistic score given by the Intent Engine. This definition for the System.Intent component tells the Dialog Engine to move on to the next state that matches a resolved intent whose accuracy rate at parsing user data is at least 40% or higher. See How Confidence Threshold Works.

Equip my bot to handle unresolved intents?

Define a state for the System.Intent’s unresolvedIntent action. unresolvedIntent is an intent that we provide for you to track the messages that couldn’t be resolved within the minimum confidence threshold. See Run Failure Reports to find out how to filter a quality report using this intent.

Example:
unresolvedIntent: "unresolved"
...
  unresolved:
    component: "System.Output"
    properties:
      text: "Sorry I don't understand that question!"
    transitions:
      return: "unresolved"
Enable components to access variable values?
Use the .value property in your expressions (${crust.value} ). To substitute a default value, use ${variable.value!\"default value\"} . For example, thick is the default value in ${crust.value!\"thick\"}. For example:
context:
  variables:
    size: "PizzaSize"
    confirm: "YES_NO"
    ...
  confirmState:
    component: "System.List"
      properties:
      options: "Yes,No"
      prompt: "You ordered a ${size.value} pizza. Is this correct?"
      variable: "confirm"
...

Use the Apache FreeMarker default operator (${variable.value!\"default value\"}) if it’s likely that a null value will be returned for a variable. You can use this operator wherever you define variable replacement in your flow, like the value definitions for variables used by system and custom components, or the variables that name states in a transitions definition. See Defining Value Expressions for the System.Output Component.

Save user values for return visits?
Within a state definition, add a variable definition with a user. prefix. See Built-In Components for Setting User Values. For example:
 checklastorder:
    component: "System.ConditionExists"
    properties:
      variable: "user.lastpizza"

To find out more about user variables, see the dialog flow for the PizzaBotWithMemory reference bot.

Exit a dialog flow and end the user session.

Use a return transition.

Example:
  printBalance:
    component: "BalanceRetrieval"
    properties:
      accountType: "${accountType.value}"
    transitions:
      return: "printBalance"
Flow Navigation and Transitions

You can set the Dialog Engine on a specific path within the dialog flow by setting the transitions property for a state. Transitions describe how the dialog forks when variable values are either set or not set. They allow you to plot the typical route through the conversation (the “happy” flow) and set alternate routes that accommodate missing values or unpredictable user behavior.

The transition definition depends on your flow sequence and on the component.
To do this... ...Use this transition
Set a default sequence in the dialog flow. To enable the Dialog Engine to move to the next state in the dialog, use an empty transition (transitions: {}) or omit a transitions definition altogether. Because they're not explicit, empty transitions make your dialog flow definition difficult to troubleshoot when it's not executing as expected. The skill throws errors when the final state in the dialog flow (that is, the state at the bottom) has an empty transition because the Dialog Engine won't know what to do next.
Specify the next state to be executed. Setting a next transition (next: "statename"), tells the Dialog Engine to jump to the state named by the next key.
Reset the conversation. Use a return transition to clear any values set for the context variables. You can define this transition with the state that ends the flow. Defining a return: "done" transition terminates the user session:
done:
  component: "System.Output"
  properties:
    text: "Your ${size.value} ${type.value} Pizza is on its way."
  transitions:
    return: "done"
Trigger conditional actions. Define the actions keys to trigger the navigation to a specific state or an action belonging to a custom component that’s executed by a backend service. If you don’t define any action keys, then the Dialog Engine relies on the default transition or a next transition (if one exists). See Transitions to find out about the specific actions that you can define for the user interface components.
Handle component errors. Set an error transition in case an error occurs when the component executes. The Dialog Engine will jump to the state that you define for the error key. If you don’t set an error transition, then the bot outputs the Oops! I’m encountering a spot of trouble message and terminates the session.
next and Default Transitions

The default, or empty, transition ({}) is an implicit transition that directs the Dialog Engine to the next state after the component executes successfully. It can suffice for strictly linear progressions that process expected user input, but not for more complicated (and realistic) user interactions. In the latter case, default transitions can result in unintended routing and, because they are implicit (they don't return a value), they make errors harder to trace. To avoid these problems, use the next transition instead of the default transition. Further, use the next transition whenever there's no error or actions defined.

The absence of explicit transitions like next, can result in the skill throwing errors. For example, if you defined the transition for the final state in the flow with a default transition, then the skill will throw an exception after the component executes because it won't know what to do next. In the Insights Pathing report, this error might indicate that an execution path didn't complete successfully even though it did despite the error.

Configuring the Dialog Flow for Unexpected Actions
When designing your dialog flow, you typically start modeling the “happy” flow, the path that the user is most likely to follow.
Scenario Solution
Instead of tapping buttons, the user responds inappropriately in this situation by entering text. To enable your bot to handle this gracefully, route to a state where the System.Intent component can resolve the text input, like textReceived: Intent in the following snippet from the CrcPizzaBot:
ShowMenu:
 component: System.CommonResponse
 properties:
   metadata: ...
   processUserMessage: true
 transitions:
   actions:
     pizza: OrderPizza
     pasta: OrderPasta
     textReceived: Intent
Users scroll back up to an earlier message and tap its options, even though they’re expected to tap the buttons in the current response.
Add an unexepectedAction transition to the defaultTransitions node that names a state that handles all of the unexpected actions:
context:
  variables:
    iresult: "nlpresult"
defaultTransitions:
  next: "ImplicitTransitionDetected"
  error: "MyErrorState"
  actions:
    unexpectedAction: "HandleUnexpectedAction"

...

  HandleUnexpectedAction:
    component: "System.Switch"
    properties:
      variable: "user.botsUnexpectedAction"
      values:
      - "pizza"
      - "pasta"
      - "order"
    transitions:
      actions:
        NONE: "ActionNoLongerAvailable"
        pizza: "OrderPizza"
        pasta: "OrderPasta"
        order: "AskPizzaSize"
Adding an unexpectedAction transition to all of the states that process a user message handles situations where a user taps the button belonging to an older message, because this action tells the Dialog Engine to transition to a single state that handles all of the unexpected actions, such as the HandleUnexpectedAction state in the OBotML snippet above. You can use different approaches to create this state:
  • You can use the System.Output or System.CommonResponse component that outputs a message like “Sorry, this option is no longer available” along with a return: “done” transition to invalidate the session so that the user can start over. For example:
    ActionNoLongerAvailable:
        component: "System.Output"
        properties:
          text: "Sorry, this action is no longer available"
        transitions:
          return: "done"
    
  • Using a System.Switch component, you can enable your bot to honor some of the request actions by transitioning to another state. Depending on the factors involved in honoring the request, you may need to create a custom component to implement the routing.

Apache FreeMarker Template Language Syntax

You can use Apache FreeMarker Template Language (FTL) to access variable values, show or hide response items, find key words in a user message, print a list of values, or display arrays that are sorted by a specific data attribute. The basic syntax for these value expressions is ${...}. You can incorporate FTL into the property definitions for various components, such as System.SetVariable and System.Output .

Note:

As illustrated by the text and rendered metadata properties of the System.CommonResponse, you can also define the expressions using the if directive (<#if>...</#if>).
To do this... ...Do this
Read values from context variables. Add the value property using dot notation:
${variablename.value}
For example:
${MyEmail.value}
Read values from context variables defined by complex entities. Use dot notation to add an additional property:
${variablename.value.property}
For example:
${MyMoney.value.totalCurrency}
If you use an expression like ${MyMoney} in a System.Output component, you will see all the properties of the referenced currency JSON object.
Create a comma-delimited list of entity values that display as buttons that are specified by the options property. Use this syntax:
${variablename.type.enumValues}
For example, for a list value entity like AccountType (whose savings, checking, and credit card values are constant and predefined for the user), you’d store these values in the accountType variable using ${accountType.type.enumValues}:
  accounts:
    component: "System.List"
    properties:
      options: "${accountType.type.enumValues}"
      prompt: "Which account?"
      variable: "accountType"
    transitions: {} 
When the user taps one the buttons, the bot stores the corresponding value in the accountType variable.
Use built-ins for strings, arrays (sequences), numbers, and dates. See Apache FreeMarker Reference. Follow the value property with a question mark (?) and the operation name:
${variable.value?ftl_function}
  • string operations:
    toLowercase:
      component: "System.SetVariable"
      properties:
        variable: "userstring"
        value: "${userstring.value?lower_case}"
      transitions: {}
    
  • array operations:
    setArrayCount:
      component: "System.SetVariable"
      properties:
        variable: "count"
        value: "${person.value?size?number}"
  • number operations:
    ${negativeValue.value?round}
  • time and date operations:
    printDateFound:
      component: "System.Output"
      properties:
        text: "Date found is: ${theDate.value.date?long?number_to_date?string.short}"
    
Concatenate FTL expressions. String the operations together using a question mark (?):
${variable.value?ftl_function1?ftl_function2}

User-Scoped Variables

When the conversation ends, the variable values that were set from the user input are destroyed. With these values gone, your bot users must resort to retracing their steps every time they return to your bot. You can spare your users this effort by defining user-scope variables in the dialog flow. Your bot can use these variables, which store the user input from previous sessions, to quickly step users through the conversation.

Unlike the session-wide variables that you declare in the context node at the start of the flow, you do not need to declare user-scoped. Any reference to a variable name that is prefixed with user. is treated as a user-scoped variable. As shown in the following dialog flow excerpt from the PizzaBotWithMemory dialog flow, these variables are identified by the user. prefix (such as user.lastsize in the checklastorder state). The user. variable persists the user ID. That ID is channel-specific, so while you can return to a conversation, or skip through an order using your prior entries on bots that run on the same channel, you can’t do this across different channels like Facebook Messenger and Amazon Alexa.
metadata:
  platformVersion: "1.0"
main: true
name: "PizzaBot"
parameters:
  age: 18
context:
  variables:
    size: "PizzaSize"
    type: "PizzaType"
    crust: "PizzaCrust"
    iResult: "nlpresult"
    sameAsLast: "YesNo"
states:
  intent:
    component: "System.Intent"
    properties:
      variable: "iResult"
    transitions:
      actions:
        OrderPizza: "checklastorder"
        CancelPizza: "cancelorder"
        unresolvedIntent: "unresolved"
  checklastorder:
    component: "System.ConditionExists"
    properties:
      variable: "user.lastsize"
    transitions:
      actions:
        exists: "lastorderprompt"
        notexists: "resolvesize"
  lastorderprompt:
    component: "System.List"
    properties:
      options: "Yes,No"
      prompt: "Same pizza as last time?"
      variable: "sameAsLast"
    transitions: {}
  rememberchoice:
    component: "System.ConditionEquals"
    properties:
      variable: "sameAsLast"
      value: "No"
    transitions:
      actions:
        equal: "resolvesize"
        notequal: "load"
...


  load:
    component: "System.CopyVariables"
    properties:
      from: "user.lastsize,user.lasttype,user.lastcrust"
      to: "size,type,crust"
    transitions: {}
Built-In Components for Setting User Values

Define the value property of the following components with expressions like “${user.age.value}” to set stored user values.

Component Uses
System.SetVariable Sets the stored user value.
System.ResetVariables Resets a stored user value.
System.CopyVariables Copies in the stored user value.
System.Output Outputs the stored user value as text.
System.ConditionExists Checks if the user-scoped variable is already in context.
System.ConditionEquals Checks for the user-scoped variable.
System.Switch Uses the stored value to switch from one state to another.

User Context

The profile property enables your bot to recognize a user’s name, local, and local time using the profile settings from the chat client. For example:
  Greeting:
    component: "System.Output"
      properties:
      text:  "Hello ${profile.firstName}, how can I help you today?"
    transitions:
      next: Intent

This is an image of the profile.firstName in the output.
Use these pre-defined variables to output context-specific for the bot user.
To do this... Use this...
Get the first name of the bot user. ${profile.firstName}
Get the last name of the bot user. ${profile.lastName}
Get the bot user’s locale. ${profile.locale} and ${profile.languageTag}. Use these variables to translate your bot to the user’s language.
Get the user’s time zone (offset in seconds). ${profile.timezoneOffset}

Auto-Numbering for Text-Only Channels

The auto-numbering framework enables your skill bot to run on text-only channels because it prefixes buttons and list options with numbers. When users can’t use tap gestures, they can still trigger the button’s postback actions by entering a number. For example, when the CrcPizzaBot runs in a channel that supports buttons, it displays Pizzas and Pastas.
A runtime image of options in non-text only channel.
But when it runs on a text-only channel, it renders the Pizza and Pasta options as text and prefixes them with sequential numbers (1. Pizza 2. Pasta).
A runtime image of options in a text-only channel.

Auto-numbering isn’t limited to text-only channels; enabling it where buttons are supported add another way for users to input their choices. For examples, users can either tap Pizza or enter 1.
A runtime image of auto-numbering with buttons.

Set Auto-Numbering for Text-Only Channels

You can set the auto-numbering feature on a global scale (meaning that it affects all components named in your dialog flow definition) or at the component level for the components that trigger postback actions, namely the System.List, System.CommonResponse, System.ResolveEntities, System.QnA, System.Webview, System.Interactive, System.OAuthAccountLinkComponent, and System.OAuth2AccountLinkComponent components.

To automatically prefix the options with sequential numbers:
  1. In the context node, add autoNumberPostbackActions: “boolean”. This, like textOnly and autoTranslate, is a common variable that can be used across all of your bots.
    context:
      variables:
        size: "PizzaSize"
        type: "PizzaType"
        crust: "PizzaCrust"
        cheese: "CheeseType"
        autoNumberPostbackActions: "boolean"
        iResult: "nlpresult"
  2. Set the autoNumberPostbackActions property to true:
      type:
        component: "System.List"
        properties:
          prompt: "What Type of Pizza do you want?"
          options: "${type.type.enumValues}"
          variable: "type"
          autoNumberPostbackActions: "true"
          footerText: "Enter a number or tap your selection."
        transitions: {}
    If you need to override auto-numbering for a particular component (either a system component or a custom component), set the autoNumberPostbackActions property to false. To override auto-numbering for a specific postback action in the System.CommonResponse, add a skipAutoNumber property and name the action.

    Note:

    Because auto-numbering gets applied through server-side processing, it only works on postback actions, not for the client-side URL actions. Consequently, components that render two button actions, one URL action, and one postback action result in a suboptimal user experience because of the inconsistent numbering of the various UI elements. For the OAuth components that render both a login URL action and a cancel postback action, only the cancel action is prefixed with a number. To maintain consistency in cases like this, set the autoNumberPostbackActions property to false .
  3. You can conditionally enable auto-numbering by setting the autoNumberPostbackActions variable with the current channel. For example:
    setAutoNumbering:
      component: "System.SetVariable"
      properties:
        variable: "autoNumberPostbackActions" 
        value: "${(system.message.channelConversation.channelType=='facebook')?then('true','false')}"
    Once you’ve set the autoNumberPostbackActions variable, you can reference it to modify the prompt text:
    prompt: "Hello ${profile.firstName}, this is our menu today<#if autoNumberPostbackActions.value>. Make your choice by entering the menu option number</#if>:"
    Likewise, you can conditionalize the footer text:
    footerText: <#if autoNumberPostbackActions.value>"Make your choice by entering the menu option number."</#if>
Conditionalized Content for Text-Only Channels

You can show or hide channel-specific messages when you reference the textOnly variable in the dialog flow-branching components like System.ConditionEquals or System.Switch. Before you can branch your flow based on text-only messages, you need to declare textOnly as a context variable and then set its value. Here are the basic steps:
  1. Add the textOnly: “boolean” variable to the context node.
    context:
    autoNumberingPostbackActions: "boolean"
    textOnly: "boolean"
  2. Reference textOnly in the variable setting components, like System.SetVariableand System.Switch

  3. Use the system.message property to expose the complete user message. The following snipppet shows how to set a boolean within the system.message expression that indicates whether a text-only channel (Twilio, in this case) is in use or not.
    setTextOnly:
      component: "System.SetVariable"
      properties:
        variable: "textOnly" 
        value: "${(system.message.channelConversation.channelType=='twilio')?then('true','false')}"
  4. Because the textOnly variable is true or false, you can conditionally enable auto-numbering for text-only channels. For example:
    setAutoNumbering:
      component: "System.SetVariable"
      properties
        variable: autoNumeringPostbackActions
        value: "$(textOnly)

You can also reference textOnly to modify parts of the text message or a button label depending on the channel.

Tip:

To clarify what you need users to do, add a FreeMarker expression that conditionally displays enhanced instructions in text-only channels.

Test the Dialog Flow

Once you have a valid dialog flow, you can test your skill bot as a whole. Be sure to validate the syntax before you test the bot.

To test the dialog flow:
  1. Click Skill Tester (This is an image of the Bot Tester icon from the left navbar.) in the left navbar.

  2. Enter a test phrase or utterance and then click Send. Click This is an image of the attachment upload icon.to test an attachment response rendered by the System.CommonResponse component.

  3. Click Conversation to see the traversal through the states.

    During testing, you can export the conversation log for offline analysis by:
    1. Turning on Skill Conversation in Settings > General.
    2. Choosing Skill Conversation Log and a time period in the Export Conversation Log dialog (accessed from the Export Conversation Log option in the tile menu). When your bot is in a production environment, be sure to turn the Skill Conversation option in the Settings page off to prevent the database from running out of space.

Custom Parameters

In your skill, you can define customer parameters to be referenced from dialog flows. After you have published the skill, you can change the values of these parameters (though you can not change other parameter details or add or delete parameters).

Custom parameters are exposed as system.config variables for use in the dialog flow definition.

Parameters that begin with da. can be used by all the skills that are registered in the same digital assistant. You can also set the value for such parameters in the digital assistant.

For example, you can add the da.faHostName, da.faPort, and vendorId parameters, and then use them in your dialog flow like this:

createVendorUrl:
  component: "System.SetVariable"
  properties:
    variable: "vendorBaseUrl"
    value: "http://${system.config.da.faHostName}:${system.config.da.faPort}/vendors/${system.config.vendorId}"

Similarly, you can access these parameters from custom components. For example, you could reference da.faHostName from a custom component with this call:

conversation.variable(“system.config.da.faHostName”)

Create a Custom Parameter

  1. Click icon to open the side menu to open the side menu, select Development > Skills, and select your skill.
  2. In the skill’s left navigation, click left navbar Settings icon..
  3. Click the Configuration tab.
  4. Click New Parameter and fill in the fields of the dialog that appears.

Modify the Value for a Custom Parameter in a Published Skill

Once you have published a skill, you can't add or delete custom parameters, but you can change their values. To do so:

  1. Click icon to open the side menu to open the side menu, select Development > Skills, and select your skill.

  2. In the skill’s left navigation, click left navbar Settings icon..

  3. Select the Configuration tab.
  4. Select the parameter, click Edit, and enter the updated value.

Set the Value for a Shared Parameter in Digital Assistant

After a skill has been published and has been added to a digital assistant, you can set the value for any shared parameters (those that are prefixed with da.) in the digital assistant:

  1. Click icon to open the side menu to open the side menu, select Development > Digital Assistants, and select your digital assistant.
  2. In the digital assistant's left navigation, click Skills icon.
  3. Select one of the skills that uses the parameter.
  4. Scroll down to the Parameters section of the page and enter a value for the parameter.

    The updated parameter value will be applied for all skills that use the parameter.