5+ ways Dialogflow CX is better than Dialogflow ES

Byaravindmc

Now that Dialogflow CX has become generally available, it is time to revisit my article Dialogflow CX vs ES: First look.

I recently released a course on Dialogflow CX.

Based on all the stuff that I noticed, here is my updated comparison.

CX makes it easier to handle conversations which go off track

In Dialogflow ES, managing conversations which went off track required lots of effort and wasn’t very easy to manage even after putting in the effort.

Since Dialogflow CX is based on a conversation state machine, when the conversation goes off track, it is like a self-loop back to the same state. (see diagram)

If you understand how state machines work, this means there is really nothing extra that you need to do when the conversation comes back on track. It just goes back to a known “good” state.

If you have tried to use input and output contexts in Dialogflow ES to manage this, you understand how much of a benefit this provides.

You can reuse intent training phrases

Once you have defined a bunch of training phrases for an intent, you can reuse them in Dialogflow CX. Since the response and the training phrases are separated in CX (unlike in ES where they belonged to the same intent), you can actually save plenty of time by reusing intents.

Slot filling retry handling is MUCH better

I have mentioned this previously too, but by providing sys.no-match-N handlers in Dialogflow CX, we can now do sensible reprompts when user provides an unexpected input.

By allowing the user to break out of slot filling without throwing away the existing information which was collected, Dialogflow CX slot filling works very well IMO. Unlike my recommendation not to use slot filling in Dialogflow ES, I think you definitely should consider using it in Dialogflow CX whenever it makes sense.

In my course, I provide an example of how to use this to more carefully manage your slot filling reprompts.

Session parameters make it much easier to keep track of user input

The concept of session parameters, which has no equivalent in ES, is a welcome improvement.

You can invoke them at any point in the conversation. See the next point for an example of this.

In fact, one of the main reasons we don’t care about conversations going off track in CX is that all parameters get saved into the overall session immediately after user provides them.

CX allows you to add more logic without creating a webhook

The different ways of moving your conversation from one state to another state is well implemented. In my view, it is quite exhaustive.

For example, in my CX course I took my Quiz Bot implemented using Dialogflow ES and converted it into a CX bot. While the ES bot had to call a webhook to calculate the final score for the quiz, the CX bot could provide a score without calling a webhook.

In the CX bot, there is a transition route (shown below) which does the following:

1 Based on what the user says

2 And a condition based on the value of a session parameter

3 It displays a message to the user

4 And updates the value of the session parameter

5 And finally transitions to a new state

Although the universe of NLU powered bot frameworks is a little too large to survey today, I would be surprised if there is any other bot framework which provides this much flexibility when it comes to developing your chatbot.

In turn, this means that Dialogflow CX is probably the gold standard when it comes to developing really complex Machine Learning powered conversational flows.

Multiple webhooks make it easier to develop your webhook locally

When you are building webhooks, it might be simpler to incrementally create webhooks locally before pushing them to production.

Since Dialogflow CX supports multiple webhook endpoints, you can do this incremental code development more easily.

Webhook timeout can be increased

This was a much requested feature in Dialogflow ES. It is now possible to set your own webhook timeout in Dialogflow CX. If you have some long running requests on your backend, it is now possible to use them in your webhook with CX.

Summary

So should you get started with Dialogflow CX right away?

Sometimes Dialogflow CX can be a little buggy.

Another issue is that the level of built-in integrations is not quite at the same level as Dialogflow ES. Here is my assessement of Dialogflow Messenger integration in CX.

Finally, you still don’t have History of conversations in CX, as of this writing. So you don’t really have a way to know what your users are saying to your bot unless you have a custom integration and you are logging all requests and responses.

With all that said, if you are building a fairly complex conversation, you should at least consider Dialogflow CX.

Note: This is my old website and is in maintenance mode. I am publishing new articles only on my new website. 

If you are not sure where to start on my new website, I recommend the following article:

Is Dialogflow still relevant in the era of Large Language Models?

Leave a Reply