The approach I have discussed in this series cannot be used in all situations.
But remember, Dialogflow CX is an improvement over Dialogflow ES. In fact, since CX uses the state machine as the primitive, it would be quite bad if every ES bot is just as complex to build in CX. 🙂
So here are some limitations:
This approach does not work for slot filling. However, I also suggest to my readers to avoid slot filling in their ES bot.
To understand why CX slot filling is completely different, you can go through the slot filling chapter in my Learn Dialogflow CX course.
If you don’t minimize context lifespan, you will end up with surplus intents in your ES chatbot.
When you have surplus intents, your bot is usually in multiple states at once, which does not translate well to this approach.
Conditional logic inside CX bot
You can use conditional logic inside a CX bot to reroute the flow. This actually makes CX better than ES, because it means the conversation designer can do more stuff without having to rely on the programmer.
At the same time, this also means that you cannot correctly translate such a flow from ES to CX using this particular approach.
Multiple output contexts in the same intent
If you have multiple output contexts in the same intent in Dialogflow ES, you are explicitly stating that your bot is entering into multiple states when that intent fires. While you can use multiple flows to translate such a bot into CX, it is quite a subjective approach.
If you rigorously follow the explicative approach to Dialogflow ES development, you will find that you can translate your ES bot to CX much more easily using this approach.