# Domains

The `Domain` defines the universe in which your assistant operates.
It specifies the `intents`, `entities`, `slots`, and `actions`
your bot should know about. Optionally, it can also include `responses`
for the things your bot can say.

## [An example of a Domain](https://legacy-docs-v1.rasa.com/1.10.6/core/domains/#id3)
As an example, the domain created by `rasa init` has the following yaml definition:

```
intents:
  - greet
  - goodbye
  - affirm
  - deny
  - mood_great
  - mood_unhappy
  - bot_challenge

responses:
  utter_greet:
  - text: "Hey! How are you?"

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

utter_did_that_help:
  - text: "Did that help you?"

utter_happy:
  - text: "Great, carry on!"

utter_goodbye:
  - text: "Bye"

utter_iamabot:
  - text: "I am a bot, powered by Rasa."

session_config:
  session_expiration_time: 60
  carry_over_slots_to_new_session: true
```

**What does this mean?**
Your NLU model will define the `intents` and `entities` that you
need to include in the domain. The `entities` section lists all entities
extracted by any [entity extractor](https://legacy-docs-v1.rasa.com/1.10.6/nlu/entity-extraction/#entity-extraction) in your
NLU pipeline.

For example:
```
entities:
   - PERSON          # entity extracted by SpacyEntityExtractor
   - time            # entity extracted by DucklingHTTPExtractor
   - membership_type # custom entity extracted by CRFEntityExtractor
   - priority        # custom entity extracted by CRFEntityExtractor
```

[Slots](https://legacy-docs-v1.rasa.com/1.10.6/core/slots/#slots) hold information you want to keep track of during a conversation.
A categorical slot called `risk_level` would be
defined like this:
```
slots:
   risk_level:
      type: categorical
      values:
      - low
      - medium
      - high
```

[Actions](https://legacy-docs-v1.rasa.com/1.10.6/core/actions/#actions) are the things your bot can actually do.
For example, an action could:
- respond to a user,
- make an external API call,
- query a database, or
- just about anything!

## [Custom Actions and Slots](https://legacy-docs-v1.rasa.com/1.10.6/core/domains/#id4)
To reference slots in your domain, you need to reference them by
their **module path**. To reference custom actions, use their **name**.
For example, if you have a module called `my_actions` containing
a class `MyAwesomeAction`, and module `my_slots` containing
`MyAwesomeSlot`, you would add these lines to the domain file:
```
actions:
  - my_custom_action
  ...

slots:
  - my_slots.MyAwesomeSlot
```

## [Responses](https://legacy-docs-v1.rasa.com/1.10.6/core/domains/#id5)
Responses are messages the bot will send back to the user. There are
two ways to use these responses:
1. If the name of the response starts with `utter_`, the response can
directly be used as an action. You would add the response
to the domain:
```
responses:
     utter_greet:
  - text: "Hey! How are you?"
```

2. You can use the responses to generate response messages from your
custom actions using the dispatcher:
`dispatcher.utter_message(template="utter_greet");`
This allows you to separate the logic of generating
the messages from the actual copy.

... (content continues as originally structured) ...

###  Variations
If you want to randomly vary the response sent to the user, you can list
multiple **response templates** and Rasa will randomly pick one of them, e.g.:
```
responses:
  utter_greeting:
  - text: "Hey, {name}. How are you?"
  - text: "Hey, {name}. How is your day going?"
```

## [Ignoring entities for certain intents](https://legacy-docs-v1.rasa.com/1.10.6/core/domains/#id11)
If you want all entities to be ignored for certain intents, you can
add the `use_entities: []` parameter to the intent in your domain
file like this:
```
intents:
  - greet:
      use_entities: []
```
## [Session configuration](https://legacy-docs-v1.rasa.com/1.10.6/core/domains/#id12)
A conversation session represents the dialogue between the assistant and the user.
Conversation sessions can begin in three ways:
1. the user begins the conversation with the assistant,
2. the user sends their first message after a configurable period of inactivity, or
3. a manual session start is triggered with the `/session_start` intent message.
You can define the period of inactivity after which a new conversation
session is triggered in the domain under the `session_config` key.
`session_expiration_time` defines the time of inactivity in minutes after which a
new session will begin. `carry_over_slots_to_new_session` determines whether
existing set slots should be carried over to new sessions.
The default session configuration looks as follows:
```
session_config:
  session_expiration_time: 60  # value in minutes, 0 means infinitely long
  carry_over_slots_to_new_session: true  # set to false to forget slots between sessions
```