Jump to Content
Developers & Practitioners

Using a Subflow in Dialogflow CX

January 11, 2022
Romin Irani

Developer Advocate

One of the best practices of software development is to refactor common code into modules and then use it across your application. A key feature of Dialogflow CX is to ensure that multiple teams are able to work on complex agents. This will require that it supports reuse of common functionality across flows, not just in a single agent but even across agents. 

In this blog post, we are going to take a look at how to use a Subflow while designing a Dialogflow CX Agent. Think of a subflow as some common functionality that you would like to utilize in one or more flows. 

Sample Agent utilizing a Subflow

We will utilize an existing Agent that has been made available for download here. Go ahead and restore the sample Agent into an Agent project following the steps given over here. Once you have restored the agent, you should be able to see the sample flow that is shown below:

https://storage.googleapis.com/gweb-cloudblog-publish/images/Agent-DefaultFlow.max-1100x1100.png

The Sample agent has our default flow and the agent currently supports queries in two different areas:

  • Get Information on Store Hours

  • Sign up for Deals

You can try out the Agent by using the Test Agent feature in Dialogflow CX console with the following phrases:

  • What are the store hours? (Store Hours page)

  • Are there any deals currently on? (Signup for Deals page)

Understanding the Subflow

Our interest in this blog post, will be on the Signup for Deals page that allows users to sign up for receiving deals on their email address. You will notice that there is a subflow Collect User Information, that is being invoked by one of the routes from Signup for Deals page. Let us take a look at this flow, which is shown below:

https://storage.googleapis.com/gweb-cloudblog-publish/images/Agent-Subflow.max-600x600.png

This subflow captures three inputs (parameters) from the user:

  • First Name

  • Last Name

  • Email Address

This is evident from the Collect User Information page and the parameter settings as shown below:

https://storage.googleapis.com/gweb-cloudblog-publish/images/Subflow-Collect-User-Information-Page-Sett.max-1000x1000.png

Additionally, we have a Route setup from this page that fires if the parameters (all of them are mandatory) have been captured and when that happens, we set a parameter personal-details-collected to “DONE” and end this flow, as shown below:

https://storage.googleapis.com/gweb-cloudblog-publish/images/Subflow-ExitRoute.max-1000x1000.png

You can think of this subflow as a common piece of functionality that you might require in more scenarios across this Agent or in other projects. We do not want to reinvent the wheel and script this every time that we need to capture these common parameters from the user. 

In essence, we are going to call the Collect User Information flow, which captures the parameters and then the parameters will need to be read in the Default Start flow, which is the parent flow. 

Understanding Parent Flow

Now that we have looked at the subflow, the Parent Flow should be easy to understand. You noticed in the earlier section that we set a parameter personal-details-collected to “DONE”. So just before we transition to the subflow, the Signup for Deals page sets the parameter to PENDING as shown below. 

https://storage.googleapis.com/gweb-cloudblog-publish/images/DefaultFlow-SignupForDeals-Page.max-2200x2200.png

Once we return from the subflow, there are two routes for this page as given below: 

https://storage.googleapis.com/gweb-cloudblog-publish/images/DefaultFlow-SignupForDeals-Routes.max-2200x2200.png

One of them goes forward to the Display Information Page if the parameters are collected. The other one again routes to the same same subflow: Collect User Information Flow. The latter should ideally not come up since in our example, we have made all the parameters for the user to be mandatory. But in case, you did not have them mandatory and had to check in the parent flow, if the parameters were provided, going back to the Subflow would have made more appropriate vis-a-vis the user experience. 

Finally, we have the Display Information Page, which simply captures the parameter values from the session and displays them. This is more of a check at this point to help us understand that the subflow was integrated and is working well.

https://storage.googleapis.com/gweb-cloudblog-publish/images/DefaultFlow-DisplayInformation-Page.max-1700x1700.png

Test the Agent

A sample Test Run of the Agent is shown below, where we exercise the route that will invoke the Capture User Information subflow. The parameters captured in that flow are then read back as session parameters in the parent flow and displayed.

https://storage.googleapis.com/gweb-cloudblog-publish/images/Agent-SampleTestRun.max-800x800.png

During the Test Run, be sure to check out the Parameters section as shown below. The parameters get populated accordingly and is a good way to check during the development process if everything is going as expected.

https://storage.googleapis.com/gweb-cloudblog-publish/images/Agent-SampleTestRun-ParameterValues.max-800x800.png

Reusing subflows is an important aspect to ensure that you are able to capture common functionality and then reuse it across Agents. This will ease the development of Agents that are complex and where multiple teams are responsible for different flows of the Agent. 

Feel free to reach out to me on Twitter @iRomin for any questions or feedback. 

References

Posted in