Overview: Look Up workflow module (Console)

Console > Workflows > Workflow modules > Overview: Look Up workflow module (Console)

This article explains the Look Up workflow module in Console.

In this article

Overview

The Look Up workflow module is used to retrieve data from an external database like Salesforce, Zendesk, or a custom database (MySQL, MS SQL, or PostgreSQL). With the Look Up module, you can query (search) data from an external database and pull it into your workflow.

For example, on an inbound interaction workflow you could use the Look Up module to:

You can create integrations between Avaya.cx and external databases in the Integrations workspace in Console (Account > Integrations).

This article explains the general structure of the Look Up module and how you can use it to pull external data into your workflows.

Configuring the Look Up module

Once you’ve added a Look Up module to your workflow, you can double-click it to configure it. By configuring the Look Up module, you can choose:

Query section

The Query section is where you build the look up query. Once you double-click a newly-created Look Up module, you’ll be presented with a screen like the screenshot below:

The initial settings available to you to edit are:

First time users of the Look Up module can safely ignore the Advanced Query and Use First Result toggles. Instead, you should focus on the Database dropdown menu.

The Database dropdown menu shows you all of the types of database you’ve configured in Console (Account > Integrations). This is where you can tell the Look Up module what type of database you want to query. 

Note: Options only appear in the Database dropdown menu if you’ve already successfully configured an integration with Salesforce, Zendesk, or a custom database.

For the purposes of this overview, we can select Salesforce as the type of database to query.

Once you’ve selected a database from the Database menu, a new dropdown menu appears: Connection. This is where you choose the specific type of connection you want to use.

In the screenshot above, we’ve selected the database connection called default. Once we select the connection, a new dropdown menu appears: Object.

The Object dropdown menu is where you choose the object that contains the data you want to retrieve. An Object is a table on the database that you can query. 

Once you select an object, a row containing three input fields appears directly below the Object dropdown menu:

In addition to these three, if you select a Type, you’ll see an additional field called Value.

These rows are where you put in search parameters for your query.

Note: You can add as many search parameters as you want to a look up.

In the example below, we’re creating a query to look up a contact based on their phone number.

Tip: Everything left of the operator is on the Salesforce side. Everything right of the operator is on the Avaya.cx side.

Another way of interpreting the query set up in the screenshot above is:

“Find the record in the Contact table where the Mobile Phone value is equal to the source phone number value.”

If the search returns a match, the next step is to Set Variables.

Set Variables section

The Set Variables section is where you can take values from the resource you looked up and map them to variables for use in the workflow.

In the screenshot below, we have an example of searching for a contact based on their source phone number (the phone number that created the interaction). We’re evaluating the source phone number against the Mobile Phone field for each record in the Contact object.

When there’s a match, that means the Look Up module has found a record where the source phone number equals the Mobile Phone value. 

If there’s a match, you can use the Set Variables section to map another data value with the contact to a value in the workflow. You could then use the variable for various purposes, including variable replacement in workflows.

Continue reading below to learn what to do if the Look Up module retrieves multiple values matching the query (or no matches).

Branching results: One, Many, and No Match

The Look Up module has three exit ports:

We’ll take a look at a scenario to see how these work.

Suppose that we have a custom database that contains a list of Catalyst Characters. The custom database has each character’s first name, last name, and location.

We want to search the database for a Catalyst Character by first name to get the employee’s location. 

One match

Let’s look at an example of the Look Up module returning one match.

In the screenshot above, we have:

There is only one record in the database where the nameFirst value is “Stefan”. 

So, the database returns one match and the Look Up module routes down the One exit port.

Many matches

Let’s look at a very similar example to the One match example above. This time, though, let’s search for a name that returns multiple results.

In the screenshot above, we have:

Notice, however, that the table we’re querying has two records with a nameFirst of Bennie.

Also notice that both of these records have different values in the location field, meaning the Look Up module can’t return a value to set as a variable.

There are three ways to remediate this:

No matches

Let's look at an example of the Look Up module not finding any results.

You’ll notice, though, that there is no John in the Catalyst Characters table.

When this happens, the Look Up module will route down the No Matches exit port. This indicates that the module wasn’t able to find any results, meaning:

If the Look Up module isn’t finding data when it should, there are three things you could try to fix the problem:

Advanced queries

Instead of using dropdown menus to build your queries, you can use advanced queries to search for data. 

Advanced queries may be more useful to users who are comfortable with query languages like SQL (for custom database queries) or SOQL (for Salesforce queries).

The Look Up module (left) has custom SQL that returns the highlighted result on the database (above).

In the example above, the query returns the value “Indiana” and maps it to a variable called customerLocation in the workflow.

Use case

Here's an example of how you could use a Look Up module:

Suppose that you have a phone number linked to a workflow so that, when customers call the number, they're routed to a workflow before being connected with an agent. You want some of your customers to be given priority over others based on data you have in a third-party database.

To accomplish this, you could add a Say+Gather module and a Look Up module to the workflow search for a priority field in an external database. On a successful match, the workflow could create the interaction with a tag (or points) indicating it’s a high-priority interaction.

Let’s take a look at the Say + Gather module. In the screenshot, the Say + Gather module is configured to ask for the customer’s case number. The Say + Gather module listens to the customer and saves the customer’s answer as a variable called caseNumber.

The next step is to look up the customer’s case number. In the screenshot below, the Look Up module is searching for the customer’s case number in the Case table on the example MySQL database. If it finds a case matching the variable stored in caseNumber, it assigns the priority field from the table to the tags on the interaction.

Those tags are then used when creating the interaction in the workflow. Note that in this workflow, if there’s are more than one matches for a case, no matches for a case, or if no case is provided, an interaction is created without a priority tag.

Visual breakdown

Exterior structure

This is the exterior structure of a Look Up module. All modules share this same structure.  

Reference the Overview: Workflow modules article to take a deeper dive into each of these components.

Interior structure

Below is the deep dive explanation for each interior area of the Look Up module.

The screenshot above is what a fresh Look Up module looks like before any configuration.

The type menu is where you select what kind of value you want to query or map to. In most circumstances, these are properties of an interaction.