Home / DialogFlow ES / Dialogflow Tip: Naming conventions for an intent which gets user input
DialogFlow ES

Dialogflow Tip: Naming conventions for an intent which gets user input

Website Name Change

I have changed the name of this website from Mining Business Data to BotFlo. I am offering a 60% off discount on both my Dialogflow ES and Dialogflow CX courses till April 20th 2021 for people who can help me spread the word about my new website.

Do you capture user input in your chatbot?

For example, do you ask them to provide their name, or email, or other information?

I have recently started using the following convention in the bots I am building (as well as advising on).

The intent

Suppose you have an intent which should get user’s email address. You can, of course, name it “EmailAddress”, but that isn’t very obvious.

Obvious to whom, you might ask.

Where you use it

The key, of course, is where you use the intent name.

One use for the intent name, for example, is in the test console. Looking at the intent name, you can tell what intent was just mapped. When you receive user input, you want the intent name to convey that some input was indeed received.

Another use is when you are accessing the agent via Dialogflow’s REST API. In this case, it is even more important to have the intent be as self-descriptive as possible because often you don’t have the additional context that you sometimes get when you are inside the Dialogflow console.

A final use for the intent name is in your training and history tab. Here again, you want the intent name to be as descriptive as possible. Almost certainly, you don’t want a misleading intent name in your training tab.

Suggested intent naming convention

Here is what I suggest. Name your intent based on the action which was completed – that is, what is the conclusion you can make from that intent firing?

If you are collecting the user’s email address, you can conclude that “UserProvidedEmailAddress”. That is how specific the intent name should be.

Context name

The next question is – how do we know that the intent is ready to accept an email address?

Usually, we set an output context on the previous intent which was triggered. For an intent which is supposed to collect an email address, we should have already set a context indicating that that’s what we wish to do.

Suggested context naming convention

So in the previous intent, set the following as the output context: awaiting_email_address

Or maybe you can use expecting_email_address.

A simple example

Let us look at a simple example. First, in your Default Welcome Intent, as soon as the user types Hi, ask them for their email address and set the output context to awaiting_email_address. This is what my welcome intent looks like:

Create another intent called “UserProvidesEmailAddress”. Now use awaiting_email_address as the input context, and add a few userSays phrases to collect the email address. This is what my intent looks like:


When you interact with the agent in the test console, you can immediately see the benefits.

The state of the agent becomes clearer

Note that the output context name for the Welcome intent immediately describes the state of the system.

A good intent name tells us that the agent is on track

For example, in the image below the intent name is “UserProvidesEmailAddress” and it is immediately clear that the agent is on track.

The history tab tells the story

This is one of nicest benefits of this approach. While you cannot always make the history tab narrate a story of how the conversation went, it is simple to observe for this particular scenario.

Just for kicks, I added an extra intent to capture the zip code, pretty much in the same way. This is what the history tab looks like:

If you can just read the history tab and already understand whether or not the agent succeeded (remember I haven’t yet shown you the UserProvidesZipCode intent), then you can see the power of using this approach. 🙂


So what do you think of this approach? Let me know in the comments.

Similar Posts


    1. In my view, for action, the convention that Dialogflow uses in most of its tutorials is most useful. For e.g. the default welcome is input.welcome and the Default Fallback is input.unknown. Similarly you can use X.Y to mean X = major intent category and Y = specific meaning.