Task Routing

Task routing allows you to specify a task to run after the current task is complete. There are two types of routing that you can use:

To use routing, you set the routing property in the post object of your task (see Post-Task Actions).

Configure Simple Routing

In a simple routing, you set the routing property to the ID of the task that you want to run next.

For example:

{
   "initial_task" : "GREET",
   "tasks" : [
      {
         "id" : "GREET",
         "pre" : {
            "response" : "Hello and welcome to the Virtual Assistant. Before we get started, I'd like to ask you a couple of questions."
         },
         "requirements": [ 
            {
               "id": "USER_NAME",
               "prompt": "What is your name?",
               "scope": "session"
            }, 
            {
               "id": "USER_COUNTRY",
               "prompt": "What country do you live in?",
               "scope": "session"
            }
         ],
         "post" : {
               "routing" : "CUSTOMER"
         }
      },
      ...
   ]
}

This example task asks the user for their name and location, and then automatically routes to the CUSTOMER task (which you must also define somewhere in the task configuration file).

Configure Conditional Routing

In conditional routing, the routing property contains a configuration object that contains details of the conditional routing.

The following table describes the properties that you can set in the routing configuration object.

Property Type Description
prompt string (Required) A prompt to send to the user to request a choice for routing.
You can include session and task variables, by inserting the variable ID in double curly brackets, for example {{MYVARIABLE}}. The variable must already be set in an earlier part of the task (for a task variable) or conversation session (for a session variable). You can optionally use the task: or session: prefix to specify the type of variable, for example {{task:MYVARIABLE}}. If you do not use a prefix, Answer Server searches for the variable in the task variables first, and then the session variables.
map array, object

(Required) One or more JSON objects that specify the user responses, and the routing option to use for that response. Each object contains the following properties:

  • match (string). Required. The value that triggers this option.
  • routing (string). Required. The task to route to next when the user response triggers this option.
  • response (string). Optional. A string to return to the user to confirm their option. You can include session and task variables, by inserting the variable ID in double curly brackets, for example {{MYVARIABLE}}. The variable must already be set in an earlier part of the task (for a task variable) or conversation session (for a session variable). You can optionally use the task: or session: prefix to specify the type of variable, for example {{task:MYVARIABLE}}. If you do not use a prefix, Answer Server searches for the variable in the task variables first, and then the session variables.
validation array, strings (Optional) A list of validators to use to validate the user selection. Specify the ID of each validator that you want to use to validate the response to use to route the conversation to a new task. You define the validators separately in the validators section of the task configuration JSON file. See Response Validation.

If you use validation, you must ensure that all the validators for a routing option map back to the value that you specify in your map object match properties.
user_cancel object (Optional) An object that defines keywords that a user can use to cancel a task, and the action to perform if they do. For details of the configuration properties, see User Cancellation.
The user_cancel options in the conditional routing section override any values that you set in the main task configuration or for the individual task.
system_cancel object (Optional) An object that defines what actions to take when the requirement receives multiple non-valid responses. For details of the configuration properties, see System Cancellation.
The system_cancel options in the conditional routing section override any values that you set in the main task configuration or for the individual task.

For example:

{
   "tasks" : [
      ...
      {
         "id" : "CUSTOMER",
         "routing" : {
            "prompt" : "Do you have an existing account with us?",
            "validation" : [ "YESNO" ],
            "map" : [
               { 
                  "match" : "yes",
                  "routing" : "EXISTING_DETAILS",
                  "response" : "Okay, {{USER_NAME}}. We'll get you the options for existing customers."
               },
               {
                  "match" : "no",
                  "routing" : "NEW_OPTIONS"
               }
            ]
         }
      }
      ...
   ]
}

This example routes users to different tasks depending on whether they are an existing or new customer.

TIP:

When Answer Server returns a routing prompt, it also returns the valid responses (the values of the match property for each object in your map array). You can use these values to present the available options to your users, particularly if you do not want to use validation in your routing object.

Use Routing in a Lua Function

When you are using a Lua script in your task configuration, you can route to the next task in your post Lua function.

Answer Server calls the post Lua function at the end of a task, when all the requirements are met. You can use this function to run an external operation, or store data that allows an operative to complete any manual portion of the task.

You can include routing in your post Lua function to control the task that Answer Server occurs next. To do this, you can use the setNextTask method. For more information, refer to the Answer Server Reference.

Task routing in the post Lua response takes precedence over any explicit task routing in the task JSON configuration.


_HP_HTML5_bannerTitle.htm