Answer Server 24.4
IDOL Answer Server Help

# 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:

- Simple. You provide the ID of the task to run after the current task is complete.
- Conditional. You specify a set of conditions (such as user selections), and specify the task to run in each case.

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.

Copyright 2016-2024 Open Text
Version 24.4 | Last updated September 2024

Send documentation feedback

Close

Send documentation feedback

To send feedback using your default email client, open an email window.

Otherwise, send your feedback and the information below to MFI-swpdl.idoldocsfeedback@opentext.com.

We appreciate your feedback!

Product: IDOL Answer Server 24.4

Topic Title: Task Routing