You are currently viewing Dialogflow 4 – Using entities, parameters and contexts

Dialogflow 4 – Using entities, parameters and contexts

Hi again,

In this post we are going to see some of the elements needed to create conversation flows.

The first thing are entities, which will help us to identify  content from users phrases. We can system predefined entities, create our own using the console, or even create and modify then in a fulfillment.

We will use entities in our training phrases to label the content and extract part of it. In our example reservation intent we have:

As you can see, and sorry for the Spanish, some of the phrases identify a city or a date, and we have assigned those values to variables, or parameters, that we will capture for later use in the fulfillment.

One example of a custom entity is the following one called “vehicle” with several values of different transportation machines and their synonyms:

The use of entities allow us to greatly reduce the number of training phrases, as any value or synonym of the entity will be detected in a training phrase with this entity labeled. In the reservation example you can see this behavior with the city names, we have just stated ” … book in Barcelona …” event the user can specify any other city.

One relevant details is that if you use synonyms, the primary name will be the one captured in the parameters, so inside the fulfillment that will be the one program with.

We have to plan entities quite carefully within a bot, as we can’t repeat words in different entities. In the example above, it might be a better idea to have separate entities for cars, motorbikes, etc., if we later need to identify cars or bikes in other intents.

The next relevant concept is contexts, which will define in what point of the conversation we are.

In our reservation intent we have defined an output context that will signal to the next steps that we are in the flow to make a reservation:

We can also create a context within a fulfillment, event adding parameters to the this context, as we can see in the following line:

agent.setContext({ name: “reservation”, lifespan: 5, parameters: { resCity: resCity, resDate: resDate  } });

And this context can be used in a fulfillment with the getContext function:

   var contextIn = agent.getContext(‘reservation’);

And its parameters would be read like this:

  resCity = contextIn.parameters.resCity

The next action would be to use this context to control if an intent is triggered or not, and this is the key for contexts. If a users says “Barcelona” with no context we will have no idea of the meaning, what if we define an intent which will accept a city name in the flow of a room reservation, then it makes a lot of sense. This is our example:

Having an “input context” this intent will only be triggered if the context is already defined and user says something that matches a training phrase.

In our Hoteles Martínez example we do this for the city and the reservation date, and then we process this information with the same function that we use for the generic reservation intent. This is our intents to functions mapping:

And taking a look to the reservation function we read the 2 variables from the parameters captured from the current intent or the context created in a previous intent:

The lifespan value specifies the number of followup intents that this context will be passed to. The alternative is to “delete” the context from the fulfillment code, something we can do with lifespan -1:

         agent.setContext({ name: “reservation”, lifespan: -1, parameters: { resCity: resCity, resDate: resDate, resLength: resLength } });

If you have noticed, the name of the intents that I have used show if they are within a conversation context; this is a good practice to quickly identify the point within the conversation that they belong to.

If you want to reference those parameters in a followup intent you can use the syntax #reservation.resCity to name the parameter in a gui response.

The next example is from the end of our chat, when we are about to finish we ask “do you want anything else?” and we activate the context “abouttoend”, and the following intent handles the negative answers within this context, saying goodbye and ending the agent with the option “end of conversation” at the very Botton.

Another option is to use “fallback intents”, that will be triggered within the conversation flow thanks to their context, when no other intent is matching the user answer, or when he/she says one of the “negative” examples of this fallback intent training phrases. To create one of this intents you need to use the right buttons … it is kind of hidden:

This complements the generic “Default Fallback Intent” that we will always have, with a tailored answer for the particular moment of the conversation.




I work for Google Cloud, but this post are personal ideas and opinions

This Post Has 2 Comments

  1. kabita soren

    This was one of the best examples which was explained very well

  2. Victor

    Me salvaste el día, tenía un problema de que aunque seteaba el contexto siempre venía vacía en el siguiente fullfilment. Lo que sucuedía era que no lo tenía especificado como contexto de entrada en la consola de Dialogflow. Es un pequeño detalle pero muy importante, esto no lo encontré en ningún tutorial, solo en el tuyo. Saludos desde Ecuador.

Leave a Reply