Home / API.AI / DialogFlow (API.AI) tutorial: Branching a conversation based on user input
API.AI

DialogFlow (API.AI) tutorial: Branching a conversation based on user input

This website contains affiliate links. See the disclosure page for more details. 

I recently came across this question on the API.AI forum:

Now, this can be a little ambiguous, so the forum member clears it up with a followup comment:

Do you need a webhook?

So, the first question is: do you absolutely need a webhook to solve this problem? Put another way, can you avoid using a webhook?

If you frame the question as “How can I avoid using a webhook?” the answer becomes a bit clearer.

Split the entity

I have come to realize an interesting thing about API.AI – there is actually a tradeoff between the number of entities you are willing to create and the complexity of the eventual webhook code you will be writing.

To put it another way:

If you are willing to split the existing entities you have defined into two or more logical groupings, you can sometimes get away with far less complexity in your overall system.

In the same thread, someone mentions that it is not possible to do this without using webhooks. In a sense, that is correct. But only if the original poster didn’t want to modify the way they defined their entities.

Defining Two entities

The thing I love about this example is that it is really a very simple way to frame this problem but it is not so simple that it becomes contrived.

So I start by defining two entities in the agent:

Defining the intents

Now that we have defined the entities, let us define two intents: one for handling MacOS, and the other for handling Windows.

The intent for email problems on Windows is very similar:

I have used the template mode here because it helps with stricter enforcement.

Testing the agent

Now, you can do a whole lot more than tamely replying with “Call Apple support” etc. For example, each intent could set different output contexts, and you can have entirely new conversation branches based on that. Or you could also simply create followup intents under these two intents and let API.AI do some of the grunt work for you.

For this simple example, we know now that if the bot responds with the appropriate response, we have achieved our goal of avoiding a webhook. The GIF below shows the web demo. And note that you should be able to replicate the results below by simply creating a new agent and adding the entities and intents I have shown (if you cannot do that for some reason, leave a comment on this post explaining what you see).

Extending this to the general case

This is why entity design for your chatbot is usually explicitly tied to intent design. If you wish to have a chatbot that you can reason about very clearly, I would suggest splitting your entities like this up to the point where you can have logical groupings (but don’t overdo it).

Of course, this means you would sometimes have more duplication in your intents. It is a tradeoff, but even if you don’t wish to split the entities like I am suggesting here, you should keep this option as another tool in your toolkit.

The recently released Zoho SalesIQ v2 allows non-programmers to build chatbots using an easy-to-use code less bot builder. What is really unique about Zoho SalesIQ is the fact that you can also integrate AI into their code less bot builder. In my Zoho SalesIQ chatbots course, I explain how to use Zoho SalesIQ to add a chatbot to your website.

"The magic key I needed as a non-programmer"

The custom payload generator was the magic key I needed (as a non-programmer) to build a good demo with rich responses in DialogFlow Messenger. I've only used it for 30 minutes and am thrilled. I've spent hours trying to figure out some of the intricacies of DialogFlow on my own. Over and over, I kept coming back to Aravind's tutorials available on-line. I trust the other functionalities I learn to use in the app will save me additional time and heartburn.

- Kathleen R
Cofounder, gathrHealth

Similar Posts