You are currently viewing Dialogflow 15 – Waiting for a process to finish

Dialogflow 15 – Waiting for a process to finish


I’ve had the request to solve this issue a couple of times, so let’s have a post on this.

The idea is that for some back-end processes, you might need to have your Dialogflow agent waiting for a “long” time until you have the process finished and you can come back with an answer to the user. One example would be making a reservation in your backend hotel reservation system … if the process takes more than 5 seconds, the maximum time a Dialogflow fulfillment request can take, you need to handle a “long” waiting for your agent.

In voice enabled chatbots long waits are not the best user experience; I would recommend to keep some user interaction, play some music, do a quiz … you decide, but it is definitely something to keep an eye on. For text only chatbot this can be less critical.

So, let’s say you have a function called “transactionIsFinished” that checks if your process has finished or not. With the following code you can create a fulfillment to wait for a few seconds (maximum is 5 including the execution time for the function):

You would need a few intents to make this work:

  1. First the intent that triggers the wait; in a real scenario it would be the request that needs that “slow” backend process to finish. In my case I just ask to wait and it is called waitStart, and it will trigger the fulfillment above
  2. An intent to call when we need to wait more time. It is called waitMore, and it prompts the user to either continue waiting or leave
  3. 2 intents with the Yes or No answers to the previous question
  4. An intent to finish the flow once the process has completed

As you can see in the code both waitMore and waitReturnAfterFinished will be called using events (as explained in this post) from the waiting fulfillment. The waitMore intent looks like this:

The user will answer with a yes or not, which will be captured by the corresponding intents, which have the input Context to limit their scope (more info on contexts here):

The No intent will finish the flow, and the Yes intent will trigger the same fulfillment code above, so we need a dual mapping for that:

With that we are all set to wait as long as the user wants to have the transaction completed. 




I work for Google Cloud, but this post are personal ideas and opinions

This Post Has 4 Comments

  1. Ludo

    thank you for this very interesting article.

    How would you solve this problem if the agent is waiting too long for a webservice to respond ? i would like to add the response to the agent before setting the followup event to “waitReturnBeforeFinished”. But that does not seem to work.

    1. jamarmu


      The issue is that we can’t control this in Dialogflow ES unless you already expected that the webhook can take some time and design the agent for that. If you reach the timeout while in a webhook the default text response will be send to the user, so for any backend call that might be delayed beyond the timeout you would need to handle it with the strategy shown in this post.

      As a side note, on Dialogflow CX you can both manage longer timeouts for the webhooks (it is configurable up to 30 seconds), and you can also manage events per page to define how to handle and failing or timing out webhook:

      DialogflowCX Webhook handling



  2. Aymal

    Hi, Our webhook is outside of google cloud how can I implement this in dialog flow CX ?

    1. jamarmu


      In Dialogflow CX you can call several webhooks using their URLs and it doesn’t matter if they are hosted in Google Cloud or not. Make sure the latency is still low, so it doesn’t impact your customer experience.

      Also in CX you don’t have a fixed timeout of 5 seconds. Each webhook that you define can have a different timeout of up to 30 seconds, so most likely you won’t need to implement waits as discussed in this article.



Leave a Reply