Some readers have sent me feedback which suggests that they started using Dialogflow thinking it is a really low code tool, only to discover that it is a lot more complex once you go past the toy chatbots.
At the same time, I also think that of all the major bot frameworks, Dialogflow provides the best tradeoff in terms power vs ease of use. My definition of a low code bot framework isn’t one which requires the least amount of code, but rather one which gives the best separation of responsibilities between developer, bot copywriter, and the person who asks for the bot to be built.
Unfortunately, some features can change Dialogflow from a low code tool to a mo'(re) code tool. So you should avoid them if you don’t want to rely on your programmer for everything.
I have talked about this a lot on my website now. While slot filling first looks like a feature which will make your Dialogflow bot more low-code, but it actually has the opposite effect.
Default context lifespan
I recommend something called the explicative approach to Dialogflow development, and one of the ideas is to question all the default settings. You are welcome to use defaults, for sure, but only after you understand their ramifications.
The wildcard entity is very powerful, no question about it. But if you don’t use it carefully, you might actually end up creating your own little mini-Dialogflow inside your agent.
Why Choose Dialogflow?
In my free 5 day course Why Choose Dialogflow I explain my views on no-code vs low-code vs more-code bot frameworks.
In my view, while you cannot build useful Dialogflow bots without writing code, it is still an excellent low code option.
But it is important for you to understand the features and how they work, so you can keep your Dialogflow agent as low code as possible.