Responses

Defining Responses

Responses go under the responses key in your domain file or in a separate "responses.yml" file. Each response name should start with utter_. For example, you could add responses for greeting and saying goodbye under the response names utter_greet and utter_bye:

domain.yml

intents:

- greet

responses:

utter_greet:

- text: "Hi there!"

utter_bye:

- text: "See you!"

If you are using retrieval intents in your assistant, you also need to add responses for your assistant's replies to these intents:

domain.yml

intents:

- chitchat

responses:

utter_chitchat/ask_name:

- text: Oh yeah, I am called the retrieval bot.

utter_chitchat/ask_weather:

- text: Oh, it does look sunny right now in Berlin.

note

Notice the special format of response names for retrieval intents. Each name starts with utter_, followed by the retrieval intent's name (here chitchat) and finally a suffix specifying the different response keys (here ask_name and ask_weather). See the documentation for NLU training examples to learn more.

Using Variables in Responses

You can use variables to insert information into responses. Within a response, a variable is enclosed in curly brackets. For example, see the variable name below:

domain.yml

responses:

utter_greet:

- text: "Hey, {name}. How are you?"

When the utter_greet response is used, Rasa automatically fills in the variable with the value found in the slot called name. If such a slot doesn't exist or is empty, the variable gets filled with None.

Another way to fill in a variable is within a custom action. In your custom action code, you can supply values to a response to fill in specific variables. If you're using the Rasa SDK for your action server,

dispatcher.utter_message(

template="utter_greet",

name="Sara"
)

If you use a different custom action server, supply the values by adding extra parameters to the responses your server returns:

{
  "events": [],
  "responses": [
    {
      "template": "utter_greet",
      "name": "Sara"
    }
  ]
}

Response Variations

You can make your assistant's replies more interesting if you provide multiple response variations to choose from for a given response name:

domain.yml

responses:

utter_greet:

- text: "Hey, {name}. How are you?"

- text: "Hey, {name}. How is your day going?"

In this example, when utter_greet gets predicted as the next action, Rasa will randomly pick one of the two response variations to use.

IDs for Responses

New in Rasa 3.6

You can now set an ID for any response. This is useful when you want to use the NLG server to generate the response.

Type for ID is string.

Example of response variations with ID:

domain.yml

responses:

utter_greet:

- id: "greet_1"
    text: "Hey, {name}. How are you?"

- id: "greet_2"
    text: "Hey, {name}. How is your day going?"

Channel-Specific Response Variations

To specify different response variations depending on which channel the user is connected to, use channel-specific response variations. In the following example, the channel key makes the first response variation channel-specific for the slack channel while the second variation is not channel-specific:

domain.yml

responses:

utter_ask_game:

- text: "Which game would you like to play on Slack?"
    channel: "slack"

- text: "Which game would you like to play?"

note

Make sure the value of the channel key matches the value returned by the name() method of your input channel. If you are using a built-in channel, this value will also match the channel name used in your credentials.yml file.

When your assistant looks for suitable response variations under a given response name, it will first try to choose from channel-specific variations for the current channel. If there are no such variations, the assistant will choose from any response variations which are not channel-specific.

caution

For each response, try to have at least one response variation without the channel key. This allows your assistant to properly respond in all environments, such as in new channels, in the shell and in interactive learning.

Conditional Response Variations

Specific response variations can also be selected based on one or more slot values using a conditional response variation. A conditional response variation is defined in the domain or responses YAML files similarly to a standard response variation but with an additional condition key. This key specifies a list of slot name and value constraints.

When a response is triggered during a dialogue, the constraints of each conditional response variation are checked against the current dialogue state. If all constraint slot values are equal to the corresponding slot values of the current dialogue state, the response variation is eligible to be used by your conversational assistant.

note

The comparison of dialogue state slot values and constraint slot values is performed by the equality "==" operator which requires the type of slot values to match too. For example, if the constraint is specified as value: true, then the slot needs to be filled with a boolean true, not the string "true".

In the following example, we will define one conditional response variation with one constraint, that the logged_in slot is set to true:

domain.yml

slots:

logged_in:
  type: bool
  influence_conversation: False

responses:

utter_greet:

- condition:
      - type: slot
        name: logged_in
        value: true
    text: "Hey, {name}. Nice to see you again! How are you?"

- text: "Welcome. How is your day going?"

In the example above, the first response variation ("Hey, {name}. Nice to see you again! How are you?") will be used whenever the utter_greet action is executed and the logged_in slot is set to true. The second variation, which has no condition, will be treated as the default and used whenever logged_in is not equal to true.

caution

It is highly recommended to always provide a default response variation without a condition to guard against those cases when no conditional response matches filled slots.

During a dialogue, Rasa will choose from all conditional response variations whose constraints are satisfied. If there are multiple eligible conditional response variations, Rasa will pick one at random.

Rich Responses

You can make responses rich by adding visual and interactive elements. There are several types of elements that are supported across many channels:

Buttons

Here is an example of a response that uses buttons:

domain.yml

responses:

utter_greet:

- text: "Hey! How are you?"

buttons:
      - title: "great"
        payload: "/mood_great"
      - title: "super sad"
        payload: "/mood_sad"

Each button in the list of buttons should have two keys:

• title: The text displayed on the buttons that the user sees.
• payload: The message sent from the user to the assistant when the button is clicked.

If you would like the buttons to also pass entities to the assistant:

domain.yml

responses:

utter_greet:

- text: "Hey! Would you like to purchase motor or home insurance?"

buttons:
      - title: "Motor insurance"
        payload: '/inform{{"insurance":"motor"}}'
      - title: "Home insurance"
        payload: '/inform{{"insurance":"home"}}'

Passing multiple entities is also possible.

Images

You can add images to a response by providing a URL to the image under the image key:

domain.yml

utter_cheer_up:

- text: "Here is something to cheer you up:"
    image: "https://i.imgur.com/nGF1K8f.jpg"

Using Responses in Conversations

If the name of the response starts with utter_, the response can directly be used as an action, without being listed in the actions section of your domain. You would add the response to the domain:

domain.yml

responses:

utter_greet:

- text: "Hey! How are you?"

You can use that same response as an action in your stories.