Dialog Nodes Explained

A single dialog can be made up out of different dialog node types, each node serving a single unique purpose. Each node has a few important topics that you’ll want to understand when you start diving into more elaborate use cases. Keep in mind that dialogs are entirely no-code, and that you as a conversation designer can easily chain them together to achieve any end-to-end integrated flow you can think of!

First off, we’ll make a distinction between the two different categories of nodes:

• Interactive nodes: nodes that require active participation/interaction from an end user where the conversational AI presents them with a question and/or some options.
• Functional nodes: nodes that are executed by Conversational AI Cloud without going back to the end-user for input.

Aside from these two categories each node can (optionally) be marked as a “startnode”. A node marked as a “start node” indicates that the conversational AI is able to enter the dialogue at that specific point in the dialog. This means that this particular node can be referenced from an article, event, or other dialogs.

Over time, as your flows become more complex, you’ll start branching out your dialogs from a linear flow, to a decision tree type flow. Its important to note that each branch of your dialog must always end with an “Output” node.

Recognition

The “recognition” node type provides an answer back to the customer and waits for a response from the end-user to push the conversation forward. It leverages rule-based entity recognition to determine its next steps, and has the ability to (optionally) provide the end-user with a number of dialog options to easily choose from.

Each recognition node type requires:

• One or multiple (contextual and/or channel-specific) outputs
• At least 1 dialog node that follows it up
• Recognition set on the relation between the recognition node, and the connected node(s)

Optionally each recognition node type can:

• Have the “recognition” steps be marked as a quick reply
• Have one of the follow dialog nodes be marked as a fallback node

Fallback nodes are automatically triggered if the user input matches none of the other condition sets defined under the “recognition” section of the dialog node.

Capture Input

The “user input” node type present the customer with a question to offer up information relevant to continue the conversational flows, like an e-mail address, order id, or discount code. This particular node provides (optional) validation steps to validate the input received from the end-user and can optionally provide (dynamic) quick replies based on captured variables.

Each user input node type requires:

• One or multiple (contextual and/or channel-specific) outputs.
• At least 1 dialog node that follows it up.
• A variable to capture the users response into.
• This can either be a dialog variable, or a conversation variable.

Optionally each user input node type can:

• Have pre-defined or dynamic (based on a dialog variable or conversation variable) quick replies
• Have input validation based on:
• Quick replies, where the provided value MUST match one of the provided quick replies; or
• Regular expressions, where the provided value MUST match the defined regular expressions, or on the provided quick replies.

In both validation scenario’s you’re required to define the behavior for when the end user's input does not pass validation. In that scenario the following options become available:

• Max retries, how many times should the conversational AI retry the request for input from the customer.
• Error message, what should be the message provided back to the end-user in case the validation fails.
• Default value, what should be the default value when the customer has repeatedly failed input validation, and the max retries has been reached.

And, last but not least, each capture input node type can have its data masked by checking the “Mask data” option. This will ensure that any input provided by the customer through this node type is not logged in Conversational AI Cloud’s analytics environment.

API Callout

The “API callout” node type solely executes an HTTP-based API callout, and aims to process its response within the context of the conversational flow. Its there to provide a solid integration between Conversational AI Cloud and third-party or custom built external API’s.

Each API callout node requires:

• An HTTP method, selected from the provided drop down menu. This indicates to the system whether to fetch data, create data, or update/delete pre-existing data.
• An endpoint URL, which lets Conversational AI Cloud know what server to call to get its response, or execute the required transaction.

Optionally each API callout node type can:

• Have pre-defined Authorization headers set to Basic Auth or Bearer Token type authentication.
• Depending on the API you’re calling these should be all you need to execute any authorized API callout.
• Edge case authentication scenario’s can be covered through the custom headers that can sent in.
• Custom headers, which allow you to define any header that needs to be sent to the connected API based on the API’s documentation.
• (Query) parameters, which allow you to send variables to the connected API in the URL.
• (Request) body, which allows you to transmit data in a JSON format, as form data, or as a custom format.

Once the request has been executed its (usually) important to also process the response from the API call you’ve done. In order to do customers can define multiple different success handlers that can extract the following from a response and store them in a dialog variable or conversation variable:

• Single property from the JSON response body.
• The entire response payload.
• The HTTP status from the response.

When defining the property selector in the success handler for an API callout node you can optionally use JMESPath to traverse the JSON response of the API. Learn more about JMESPath.

In the scenario that the API callout doesn’t go as planned, there’s also the optional error handler. The error handler allows you to:

• Stop the dialog in case of an unexpected error response status code
• Define a custom error output when the dialog is stopped
• Exclude one or multiple HTTP status codes from the error handler flow

Logical Step

The “Logical Step” node type allows you to make decisions based on the values of dialog variables or conversation variables you’ve gathered so far during the conversation with the end-user. Important to note is that a logical step will require you to have one or multiple follow up dialog nodes to point to in the conditions.

Each condition (referencing a follow up dialog node) must:

• Reference a dialog variable or conversation variable.
• Have a pre-defined condition selected like equals, empty, not empty or less than
• A value to compare the variable selected in the “variable” section

Optionally each logical step node type can have one of its child nodes marked as a “fallback node” which means that if none of the other explicitly defined conditions are matched, the conversational flow should flow to the “fallback node”.

When defining logical step conditions the conditions to match a single child node can be defined as:

• “Or” conditions, which means that the value must be either X or Y
• “And” conditions, which means that value must both X and Y

Customers can determine themselves which combination or AND and OR statements are required to built out their desired conversational flows.

Output

The “Output” node type allows you to finalise a branch of your dialog. It can either provide an answer directly to the customer, or reference a dialog or article. Its answer possibilities are similar to those of any Conversational AI Cloud article, where answers can be channel-specific, contextual, and have metadata attributes set.

Go To

The “Go To” node type allows you to jump between different parts of the dialog. This means that at the end of 1 branch of the dialog, you can reference back to the start of that same dialog, or another part of the dialog based on the state of the conversation.