Bahasa Rasa

Session configuration#

A conversation session represents the dialogue between the assistant and the user. Conversation sessions can begin in three ways:

the user begins the conversation with the assistant,

the user sends their first message after a configurable period of inactivity, or

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.

Available parameters are:

The default session configuration looks as follows:

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

This means that if a user sends their first message after 60 minutes of inactivity, a new conversation session is triggered, and that any existing slots are carried over into the new session. Setting the value of session_expiration_time to 0 means that sessions will not end (note that the action_session_start action will still be triggered at the very beginning of conversations).

A session start triggers the default action action_session_start. Its default implementation moves all existing slots into the new session. Note that all conversations begin with an action_session_start. Overriding this action could for instance be used to initialize the tracker with slots from an external API call, or to start the conversation with a bot message. The docs on Customizing the session start action shows you how to do that.

The config key in the domain file maintains the store_entities_as_slots parameter. This parameter is used only in the context of reading stories and turning them into trackers. If the parameter is set to True, this will result in slots being implicitly set from entities if applicable entities are present in the story. When an entity matches the from_entity slot mapping, store_entities_as_slots defines whether the entity value should be placed in that slot. Therefore, this parameter skips adding an explicit slot_was_set step manually in the story. By default, this behaviour is switched on.

You can turn off this functionality by setting the store_entities_as_slots parameter to false:

store_entities_as_slots: false

If you're looking for information on the config.yml file, check out the docs on Model Configuration.

A story is a representation of a conversation between a user and an AI assistant, converted into a specific format where user inputs are expressed as intents (and entities when necessary), while the assistant's responses and actions are expressed as action names.

Here's an example of a dialogue in the Rasa story format:

- story: collect restaurant booking info # name of the story - just for debugging

- intent: greet # user message with no entities

- action: utter_ask_howcanhelp

- intent: inform # user message with entities

- action: utter_on_it # action that the bot should execute

- action: utter_ask_cuisine

- action: utter_ask_num_people

While writing stories, you do not have to deal with the specific contents of the messages that the users send. Instead, you can take advantage of the output from the NLU pipeline, which lets you use just the combination of an intent and entities to refer to all the possible messages the users can send to mean the same thing.

It is important to include the entities here as well because the policies learn to predict the next action based on a combination of both the intent and entities (you can, however, change this behavior using the use_entities attribute).

All actions executed by the bot, including responses are listed in stories under the action key.

You can use a response from your domain as an action by listing it as one in a story. Similarly, you can indicate that a story should call a custom action by including the name of the custom action from the actions list in your domain.

During training, Rasa does not call the action server. This means that your assistant's dialogue management model doesn't know which events a custom action will return.

Because of this, events such as setting a slot or activating/deactivating a form have to be explicitly written out as part of the stories. For more info, see the documentation on Events.

Slot events are written under slot_was_set in a story. If this slot is set inside a custom action, add the slot_was_set event immediately following the custom action call. If your custom action resets a slot value to None, the corresponding event for that would look like this:

- story: set slot to none

# ... other story steps

- action: my_custom_action

There are three kinds of events that need to be kept in mind while dealing with forms in stories.

A form action event (e.g. - action: restaurant_form) is used in the beginning when first starting a form, and also while resuming the form action when the form is already active.

A form activation event (e.g. - active_loop: restaurant_form) is used right after the first form action event.

A form deactivation event (e.g. - active_loop: null), which is used to deactivate the form.

In order to get around the pitfall of forgetting to add events, the recommended way to write these stories is to use interactive learning.

Select which actions should receive domain#

You can control if an action should receive a domain or not.

To do this you must first enable selective domain in you endpoint configuration for action_endpoint in endpoints.yml.

url: "http://localhost:5055/webhook" # URL to your action server

enable_selective_domain: true

After selective domain for custom actions is enabled, domain will be sent only to those custom actions which have specifically stated that they need it. Custom actions inheriting from rasa-sdk FormValidationAction parent class are an exception to this rule as they will always have the domain sent to them. To specify if an action needs the domain add {send_domain: true} to custom action in the list of actions in domain.yml:

- action_hello_world: {send_domain: True} # will receive domain

- action_calculate_mass_of_sun # will not receive domain

- validate_my_form # will receive domain

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:

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

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.

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.

Calling Responses as Actions#

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:

- text: "Hey! How are you?"

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

- action: utter_greet

When the utter_greet action runs, it will send the message from the response back to the user.

If you want to change the text, or any other part of the response, you need to retrain the assistant before these changes will be picked up.

Ignoring Entities for Certain Intents#

To ignore all entities for certain intents, you can add the use_entities: [] parameter to the intent in your domain file like this:

To ignore some entities or explicitly take only certain entities into account you can use this syntax:

You can only use_entities or ignore_entities for any single intent.

Excluded entities for those intents will be unfeaturized and therefore will not impact the next action predictions. This is useful when you have an intent where you don't care about the entities being picked up.

If you list your intents without a use_entities or ignore_entities parameter, the entities will be featurized as normal.

It is also possible to ignore an entity for all intents by setting the influence_conversation flag to false for the entity itself. See the entities section for details.

Excluded entities for intents will be unfeaturized and therefore will not impact the next action predictions. This is useful when you have an intent where you don't care about the entities being picked up.

If you list your intents without this parameter, and without setting influence_conversation to false for any entities, all entities will be featurized as normal.

If you want these entities not to influence action prediction via slots either, set the influence_conversation: false parameter for slots with the same name.

As of 3.1, you can use the influence_conversation flag under entities. The flag can be set to false to declare that an entity should not be featurized for any intents. It is a shorthand syntax for adding an entity to the ignore_entities list of every intent in the domain. The flag is optional and default behaviour remains unchanged.

The entities section lists all entities that can be extracted by any entity extractor in your NLU pipeline.

- PERSON # entity extracted by SpacyEntityExtractor

- time # entity extracted by DucklingEntityExtractor

- membership_type # custom entity extracted by DIETClassifier

- priority # custom entity extracted by DIETClassifier

When using multiple domain files, entities can be specified in any domain file, and can be used or ignored by any intent in any domain file.

If you are using the feature Entity Roles and Groups you also need to list the roles and groups of an entity in this section.

- city: # custom entity extracted by DIETClassifier

- topping: # custom entity extracted by DIETClassifier

- size: # custom entity extracted by DIETClassifier

By default, entities influence action prediction. To prevent extracted entities from influencing the conversation for specific intents you can ignore entities for certain intents. To ignore an entity for all intents, without having to list it under the ignore_entities flag of each intent, you can set the flag influence_conversation to false under the entity:

influence_conversation: false

This syntax has the same effect as adding the entity to the ignore_entities list for every intent in the domain.

Explicitly setting influence_conversation: true does not change any behaviour. This is the default setting.

Slots are your bot's memory. They act as a key-value store which can be used to store information the user provided (e.g their home city) as well as information gathered about the outside world (e.g. the result of a database query).

Slots are defined in the slots section of your domain with their name, type and if and how they should influence the assistant's behavior. The following example defines a slot with name "slot_name", type text and predefined slot mapping from_entity.

Validating Form Input#

After extracting a slot value from user input, you can validate the extracted slots. By default Rasa Open Source only validates if any slot was filled after requesting a slot.

Forms no longer raise ActionExecutionRejection if nothing is extracted from the user’s utterance for any of the required slots.

You can implement a Custom Action validate_ to validate any extracted slots. Make sure to add this action to the actions section of your domain:

- validate_restaurant_form

When the form is executed it will run your custom action.

This custom action can extend FormValidationAction class to simplify the process of validating extracted slots. In this case, you need to write functions named validate_ for every extracted slot.

The following example shows the implementation of a custom action which validates that the slot named cuisine is valid.

from typing import Text, List, Any, Dict

from rasa_sdk import Tracker, FormValidationAction

from rasa_sdk.executor import CollectingDispatcher

from rasa_sdk.types import DomainDict

class ValidateRestaurantForm(FormValidationAction):

def name(self) -> Text:

return "validate_restaurant_form"

def cuisine_db() -> List[Text]:

"""Database of supported cuisines"""

return ["caribbean", "chinese", "french"]

def validate_cuisine(

dispatcher: CollectingDispatcher,

) -> Dict[Text, Any]:

"""Validate cuisine value."""

if slot_value.lower() in self.cuisine_db():

return {"cuisine": slot_value}

return {"cuisine": None}

You can also extend the Action class and retrieve extracted slots with tracker.slots_to_validate to fully customize the validation process.

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.

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:

influence_conversation: False

influence_conversation: False

text: "Hey, {name}. Nice to see you again! How are you?"

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

- action: action_log_in

- action: utter_greet

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.

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. For example, consider the following response:

text: "Hey, {name}. Nice to see you again! How are you?"

name: eligible_for_upgrade

text: "Welcome, {name}. Did you know you are eligible for a free upgrade?"

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

If logged_in and eligible_for_upgrade are both set to true then both the first and second response variations are eligible to be used, and will be chosen by the conversational assistant with equal probability.

You can continue using channel-specific response variations alongside conditional response variations as shown in the example below.

influence_conversation: False

influence_conversation: False

text: "Hey, {name}. Nice to see you again on Slack! How are you?"

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

Rasa will prioritize the selection of responses in the following order:

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

Here is an example of a response that uses buttons:

- text: "Hey! How are you?"

payload: "/mood_great"

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

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

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

- title: "Motor insurance"

payload: '/inform{{"insurance":"motor"}}'

- title: "Home insurance"

payload: '/inform{{"insurance":"home"}}'

Passing multiple entities is also possible with:

'/intent_name{{"entity_type_1":"entity_value_1", "entity_type_2": "entity_value_2"}}'

You can use buttons to overwrite the NLU prediction and trigger a specific intent and entities.

Messages starting with / are sent handled by the RegexInterpreter, which expects NLU input in a shortened /intent{entities} format. In the example above, if the user clicks a button, the user input will be classified as either the mood_great or mood_sad intent.

You can include entities with the intent to be passed to the RegexInterpreter using the following format:

/inform{"ORG":"Rasa", "GPE":"Germany"}

The RegexInterpreter will classify the message above with the intent inform and extract the entities Rasa and Germany which are of type ORG and GPE respectively.

You need to write the /intent{entities} shorthand response with double curly braces in domain.yml so that the assistant does not treat it as a variable in a response and interpolate the content within the curly braces.

Keep in mind that it is up to the implementation of the output channel how to display the defined buttons. For example, some channels have a limit on the number of buttons you can provide. Check your channel's documentation under Concepts > Channel Connectors for any channel-specific restrictions.

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

- text: "Here is something to cheer you up:"

image: "https://i.imgur.com/nGF1K8f.jpg"

Custom Slot Mappings#

You can define custom slot mappings using slot validation actions when none of the predefined mappings fit your use case. You must define this slot mapping to be of type custom, for example:

action: action_calculate_day_of_week

You can also use the custom slot mapping to list slots that will be filled by arbitrary custom actions in the course of a conversation, by listing the type and no specific action. For example:

This slot will not be updated on every user turn, but only once a custom action that returns a SlotSet event for it is predicted.

You can provide an initial value for a slot in your domain file:

Responses are actions that send a message to a user without running any custom code or returning events. These responses can be defined directly in the domain file under the responses key and can include rich content such as buttons and attachments. For more information on responses and how to define them, see Responses.

Forms are a special type of action meant to help your assistant collect information from a user. Define forms under the forms key in your domain file. For more information on form and how to define them, see Forms.

Actions are the things your bot can actually do. For example, an action could:

All custom actions should be listed in your domain, except responses which need not be listed under actions: as they are already listed under responses:.

Slots and Conversation Behavior#

You can specify whether or not a slot influences the conversation with the influence_conversation property.

If you want to store information in a slot without it influencing the conversation, set influence_conversation: false when defining your slot.

The following example defines a slot age which will store information about the user's age, but which will not influence the flow of the conversation. This means that the assistant will ignore the value of the slot each time it predicts the next action.

influence_conversation: false

When defining a slot, if you leave out influence_conversation or set it to true, that slot will influence the next action prediction, unless it has slot type any. The way the slot influences the conversation will depend on its slot type.

The following example defines a slot home_city that influences the conversation. A text slot will influence the assistant's behavior depending on whether the slot has a value. The specific value of a text slot (e.g. Bangalore or New York or Hong Kong) doesn't make any difference.

influence_conversation: true

As an example, consider the two inputs "What is the weather like?" and "What is the weather like in Bangalore?" The conversation should diverge based on whether the home_city slot was set automatically by the NLU. If the slot is already set, the bot can predict the action_forecast action. If the slot is not set, it needs to get the home_city information before it is able to predict the weather.

Storing true or false values.

If influence_conversation is set to true, the assistant's behavior will change depending on whether the slot is empty, set to true or set to false. Note that an empty bool slot influences the conversation differently than if the slot was set to false.

Storing slots which can take one of N values.

If influence_conversation is set to true, the assistant's behavior will change depending on the concrete value of the slot. This means the assistant's behavior is different depending on whether the slot in the above example has the value low, medium, or high.

A default value __other__ is automatically added to the user-defined values. All values encountered which are not explicitly defined in the slot's values are mapped to __other__. __other__ should not be used as a user-defined value; if it is, it will still behave as the default to which all unseen values are mapped.

Storing real numbers.

max_value=1.0, min_value=0.0

If influence_conversation is set to true, the assistant's behavior will change depending on the value of the slot. If the value is between min_value and max_value, the specific value of the number is used. All values below min_value will be treated as min_value, and all values above max_value will be treated as max_value. Hence, if max_value is set to 1, there is no difference between the slot values 2 and 3.5.

Storing arbitrary values (they can be of any type, such as dictionaries or lists).

Slots of type any are always ignored during conversations. The property influence_conversation cannot be set to true for this slot type. If you want to store a custom data structure which should influence the conversation, use a custom slot type.

Maybe your restaurant booking system can only handle bookings for up to 6 people. In this case you want the value of the slot to influence the next selected action (and not just whether it's been specified). You can do this by defining a custom slot class.

The code below defines a custom slot class called NumberOfPeopleSlot. The featurization defines how the value of this slot gets converted to a vector so Rasa machine learning model can deal with it. The NumberOfPeopleSlot has three possible “values”, which can be represented with a vector of length 2.

from rasa.shared.core.slots import Slot

class NumberOfPeopleSlot(Slot):

def feature_dimensionality(self):

def as_feature(self):

r = [0.0] * self.feature_dimensionality()

You can implement a custom slot class as an independent python module, separate from custom action code. Save the code for your custom slot in a directory alongside an empty file called "__init__.py" so that it will be recognized as a python module. You can then refer to the custom slot class by it's module path.

For example, say you have saved the code above in "addons/my_custom_slots.py", a directory relative to your bot project:

│ └── my_custom_slots.py

Your custom slot type's module path is then addons.my_custom_slots.NumberOfPeopleSlot. Use the module path to refer to the custom slot type in your domain file:

type: addons.my_custom_slots.NumberOfPeopleSlot

influence_conversation: true

Now that your custom slot class can be used by Rasa, add training stories that diverge based on the value of the people slot. You could write one story for the case where people has a value between 1 and 6, and one for a value greater than six. You can choose any value within these ranges to put in your stories, since they are all featurized the same way (see the featurization table above).

- story: collecting table info

# ... other story steps

- action: action_book_table

- story: too many people at the table

# ... other story steps

- action: action_explain_table_limit

As of 3.0, slot mappings are defined in the slots section of the domain. This change removes the implicit mechanism of setting slots via auto-fill and replaces it with a new explicit mechanism of setting slots after every user message. You will need to explicitly define slot mappings for each slot in the slots section of domain.yml. If you are migrating from an earlier version, please read through the migration guide to update your assistant.

Rasa comes with four predefined mappings to fill slots based on the latest user message.

In addition to the predefined mappings, you can define custom slot mappings. All custom slot mappings should contain a mapping of type custom.

Slot mappings are specified as a YAML list of dictionaries under the key mappings in the domain file. Slot mappings are prioritized in the order they are listed in the domain. The first slot mapping found to apply will be used to fill the slot.

The default behavior is for slot mappings to apply after every user message, regardless of the dialogue context. To make a slot mapping apply only within the context of a form see Mapping Conditions. There is one additional default limitation on applying from_entity slot mappings in the context of a form; see unique from_entity mapping matching for details.

Note that you can also define lists of intents for the optional parameters intent and not_intent.

The from_entity slot mapping fills slots based on extracted entities. The following parameters are required:

The following parameters are optional and can be used to further specify when the mapping applies:

not_intent: excluded_intent

There is an intentional limitation on applying from_entity slot mappings in the context of a form. When a form is active, a from_entity slot mapping will be applied only if one or more of the following conditions are met:

This limitation exists to prevent a form from filling multiple required slots with the same extracted entity value.

For example, in the example below, an entity date uniquely sets the slot arrival_date, an entity city with a role from uniquely sets the slot departure_city and an entity city with a role to uniquely sets the slot arrival_city, therefore they can be used to fit corresponding slots even if these slots were not requested. However, entity city without a role can fill both departure_city and arrival_city slots, depending which one is requested, so if an entity city is extracted when slot arrival_date is requested, it'll be ignored by the form.

Note that the unique from_entity mapping constraint will not prevent filling slots which are not in the active form's required_slots; those mappings will apply as usual, regardless of the uniqueness of the mapping. To limit applicability of a slot mapping to a specific form, see Mapping Conditions.

The from_text mapping will use the text of the last user utterance to fill the slot slot_name. If intent_name is None, the slot will be filled regardless of intent name. Otherwise, the slot will only be filled if the user's intent is intent_name.

The slot mapping will not apply if the intent of the message is excluded_intent.

not_intent: excluded_intent

To maintain the 2.x form behavior when using from_text slot mappings, you must use mapping conditions, where both active_loop and requested_slot keys are defined.

The from_intent mapping will fill slot slot_name with value my_value if user intent is intent_name. If you choose not to specify the parameter intent, the slot mapping will apply regardless of the intent of the message as long as the intent is not listed under not_intent parameter.

The following parameter is required:

The following parameters are optional and can be used to further specify when the mapping applies:

Note that if you choose not to define the parameter intent, the slot mapping will apply regardless of the intent of the message as long as the intent is not listed under the not_intent parameter.

not_intent: excluded_intent

The from_trigger_intent mapping will fill slot slot_name with value my_value if a form is activated by a user message with intent intent_name. The slot mapping will not apply if the intent of the message is excluded_intent.

- type: from_trigger_intent

not_intent: excluded_intent

To apply a slot mapping only within the context of a form, specify the name of the form in the conditions key of a slot mapping. Conditions list the form name(s) for which the mapping is applicable in the active_loop key.

Slot mappings can now specify null as the value of active_loop to indicate that the slot should only be filled when no form is active. Note that requested_slot cannot be used in conjunction with active_loop: null.

Conditions can also include the name of the requested_slot. If requested_slot is not mentioned, then the slot will be set if relevant information is extracted, regardless of which slot is being requested by the form.

- active_loop: your_form

requested_slot: slot_name

- active_loop: another_form

If conditions are not included in a slot mapping, the slot mapping will be applicable regardless of whether any form is active. As long as a slot is listed in a form's required_slots, the form will prompt for the slot if it is empty when the form is activated.

Dynamic Form Behavior#

By default Rasa Open Source will ask for the next empty slot from the slots listed for your form in the domain file. If you use custom slot mappings and the FormValidationAction, it will ask for the first empty slot returned by the required_slots method. If all slots in required_slots are filled the form will be be deactivated.

If needed, you can update the required slots of your form dynamically. This is, for example, useful when you need further details based on how a previous slot was filled or you want to change the order in which slots are requested.

If you are using the Rasa SDK, we recommend you to use the FormValidationAction and override required_slots to fit your dynamic behavior. You should implement a method extract_ for every slot which doesn't use a predefined mapping, as described in Custom Slot Mappings. The example below will ask the user if they want to sit in the shade or in the sun in case they said they want to sit outside.

from typing import Text, List, Optional

from rasa_sdk.forms import FormValidationAction

class ValidateRestaurantForm(FormValidationAction):

def name(self) -> Text:

return "validate_restaurant_form"

async def required_slots(

slots_mapped_in_domain: List[Text],

dispatcher: "CollectingDispatcher",

domain: "DomainDict",

) -> Optional[List[Text]]:

additional_slots = ["outdoor_seating"]

if tracker.slots.get("outdoor_seating") is True:

additional_slots.append("shade_or_sun")

return additional_slots + slots_mapped_in_domain

Calling Responses from Custom Actions#

You can use the responses to generate response messages from your custom actions. If you're using Rasa SDK as your action server, you can use the dispatcher to generate the response message, for example:

from rasa_sdk.interfaces import Action

class ActionGreet(Action):

return 'action_greet'

def run(self, dispatcher, tracker, domain):

dispatcher.utter_message(template="utter_greet")

If you use a different custom action server, your server should return the following JSON to call the utter_greet response:

"template":"utter_greet"

To use forms with Rasa Open Source you need to make sure that the Rule Policy is added to your policy configuration. For example:

Define a form by adding it to the forms section in your domain. The name of the form is also the name of the action which you can use in stories or rules to handle form executions. You also need to define slot mappings for each slot which your form should fill. You can specify one or more slot mappings for each slot to be filled.

The following example form restaurant_form will fill the slot cuisine from an extracted entity cuisine and slot num_people from entity number.

You can define a list of intents to ignore for the whole form under the ignored_intents key. Intents listed under ignored_intents will be added to the not_intent key of each slot mapping in the form.

For example, if you do not want any of the required slots of a form to be filled when the intent is chitchat, then you would need to define the following (after the form name and under the ignored_intents keyword):

The required_slots keyword was introduced. The following syntax is deprecated and will be removed in 3.0.0:

# this format is deprecated

Once the form action gets called for the first time, the form gets activated and will prompt the user for the next required slot value. It does this by looking for a response called utter_ask__ or utter_ask_ if the former isn't found. Make sure to define these responses in your domain file for each required slot.

To activate a form you need to add a story or rule, which describes when the assistant should run the form. In the case a specific intent triggering a form, you can for example use the following rule:

- rule: Activate form

- intent: request_restaurant

- action: restaurant_form

- active_loop: restaurant_form

The active_loop: restaurant_form step indicates that the form should be activated after restaurant_form was run.

A form will automatically deactivate itself once all required slots are filled. You can describe your assistant's behavior for the end of a form with a rule or a story. If you don't add an applicable story or rule, the assistant will automatically listen for the next user message after the form is finished. The following example runs the utterance utter_all_slots_filled as soon as the form your_form filled all required slots.

# Condition that form is active.

- active_loop: restaurant_form

# Form is deactivated

- action: restaurant_form

- requested_slot: null

# The actions we want to run when the form is submitted.

- action: utter_submit

- action: utter_slots_values

Users might want to break out of a form early. Please see Writing Stories / Rules for Unhappy Form Paths on how to write stories or rules for this case.

Rasa Open Source comes with four predefined mappings to fill the slots of a form based on the latest user message. Please see Custom Slot Mappings if you need a custom function to extract the required information.

The from_entity mapping fills slots based on extracted entities. It will look for an entity called entity_name to fill a slot slot_name. If intent_name is None, the slot will be filled regardless of intent name. Otherwise, the slot will only be filled if the user's intent is intent_name.

If role_name and/or group_name are provided, the role/group label of the entity also needs to match the given values. The slot mapping will not apply if the intent of the message is excluded_intent. Note that you can also define lists of intents for the parameters intent and not_intent.

not_intent: excluded_intent

In from_entity mapping, when an extracted entity uniquely maps onto a slot, the slot will be filled even if this slot wasn't requested by the form. The extracted entity will be ignored if the mapping is not unique.

In the example above, an entity date uniquely sets the slot arrival_date, an entity city with a role from uniquely sets the slot departure_city and an entity city with a role to uniquely sets the slot arrival_city, therefore they can be used to fit corresponding slots even if these slots were not requested. However, entity city without a role can fill both departure_city and arrival_city slots, depending which one is requested, so if an entity city is extracted when slot arrival_date is requested, it'll be ignored by the form.

The from_text mapping will use the text of the next user utterance to fill the slot slot_name. If intent_name is None, the slot will be filled regardless of intent name. Otherwise, the slot will only be filled if the user's intent is intent_name.

The slot mapping will not apply if the intent of the message is excluded_intent. Note that you can define lists of intents for the parameters intent and not_intent.

not_intent: excluded_intent

The from_intent mapping will fill slot slot_name with value my_value if user intent is intent_name or None. The slot mapping will not apply if the intent of the message is excluded_intent. Note that you can also define lists of intents for the parameters intent and not_intent.

The from_intent slot mapping will not apply during the initial activation of the form. To fill a slot based on the intent that activated the form, use the from_trigger_intent mapping.

not_intent: excluded_intent

The from_trigger_intent mapping will fill slot slot_name with value my_value if the form was activated by a user message with intent intent_name. The slot mapping will not apply if the intent of the message is excluded_intent. Note that you can also define lists of intents for the parameters intent and not_intent.

- type: from_trigger_intent

not_intent: excluded_intent