Dialogflow CX short for Dialogflow Customer Experience is a recent launch from Google. It provides a new way for designing agents, taking a state machine approach to agent design. This gives you a clear and explicit control over a conversation, a better end-user experience, and a better development workflow. The older version of Dialogflow which is Dialogflow ES short for Dialogflow Essentials is still supported but the Dialogflow CX should allow chatbots with higher complexity to be built more seamlessly using a visual editor and not require one to write complex code.
Flows and Pages as Building Blocks:
Flows and Pages are the building blocks of a CX agent. In the conversation path visualization graph, pages are the nodes. The pages manage the operations that the user performs within a flow.
Flows are like sub-agents. We can think of flows as Dialogflow ES Mega Agents. In CX, the mega agents are replaced by great flexibility in managing flows, which can also be developed by different teams. An agent can have any number of flows. Each flow is associated with multiple pages.
In the ES version, the context was used to determine the control of the conversation flow. Dialogflow CX completely eliminates the concept of the input and output contexts. Instead, pages are used to move the conversation forward.
The most interesting part is the interactive visualizations that allow developers to quickly see, understand, and edit their work. ES is mostly text-based editing. However, CX has a visual flow graphical editor to design our conversation paths.
Every page has the following elements:
Entry Dialog – defines the agent’s response when a page is active. At any point in the conversation, only one page is considered active and the flow associated with that page.
Parameters – are used to collect critical information from the end-user. In Dialogflow CX parameters have a session-level scope. This means, when we collect user input, we need some way to keep track of what information they provided in the prior steps. In Dialogflow ES, we have a concept of context lifespan for this purpose. But in CX, session-level parameters are built-in automatically.
Routes – Two types: Intent requirement & Conditional requirements which are used to control the flow.
Route Groups – If many pages have a common set of routes, then we can define route groups and use them in the required pages.
- Each flow can have multiple versions. (Agent Settings > Version> Add Version)
- We can create any number of custom environments and deploy the flow versions to separate serving environments. (Agent Settings > Environment > Add Environment)
- While testing the agent in the simulator, we can choose the environment of our choice and test a particular environment.
Differences Between the Two Versions:
|Category||ES Agent||CX Agent|
|Console user experience||Mostly text forms||Visual graphs showing conversation paths and text forms for configurations|
|Intent reusability||Intents are coupled with fulfillment, events, and responses; specific to a conversation state, so difficult to reuse||Intents are simplified to remove this coupling and made highly reusable|
|Agents per project||1||100|
|Recommended agent size||Up to medium size agents||Up to very large|
|Recommended agent complexity||Up to moderately complex agents||Up to highly complex|
|Text||$20 per 100 chat sessions|
|Audio input/output||$45 per 100 voice sessions|
|Other session requests||Free|
1. Only the English language is supported.
2. Telephony is the only integration possible.
3. System extensions do not work.
4. Knowledge connectors are not supported.
When to use ES vs CX:
Bot complexity – If the bot is simple, then ES will just do fine. CX is recommended only for complex bots.
Bot budget – If there is a tight budget, prefer ES.
Please check out our video blog where we demonstrate the features of Dialogflow CX along with when to use Dialogflow Essentials vs Dialogflow CX. Or check it out directly on YouTube: