## 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`:

```yaml
domain.yml

intents:

- greet

responses:

utter_greet:
  - text: "Hi there!"

utter_bye:
  - text: "See you!"
```

If you are using [retrieval intents](https://legacy-docs-oss.rasa.com/docs/rasa/next/glossary#retrieval-intent) in your assistant, you also need to add responses for your assistant's replies to these intents:

```yaml
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](https://legacy-docs-oss.rasa.com/docs/rasa/next/training-data-format#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:

```yaml
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](https://legacy-docs-oss.rasa.com/docs/rasa/next/custom-actions). 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, you can pass a value for the variable as a keyword argument to [`dispatcher.utter_message`](https://legacy-docs-oss.rasa.com/docs/rasa/next/action-server/sdk-dispatcher):

```python
dispatcher.utter_message(
  template="utter_greet",
  name="Sara"
)
```

If you use a [different custom action server](https://legacy-docs-oss.rasa.com/docs/rasa/next/action-server#other-action-servers), supply the values by adding extra parameters to the responses your server returns:

```json
{
  "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:

```yaml
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](https://legacy-docs-oss.rasa.com/docs/rasa/next/nlg) to generate the response.

Type for ID is string.

Example of response variations with ID:

```yaml
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:

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

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

```yaml
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?"
```

The first response variation 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`.

### 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:

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