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:

1. Search for the customer’s data in Salesforce (like a customer’s mobile number)

2. Pull the data into the workflow

3. Use the data when creating the interaction so the queue user has the most up-to-date and relevant information to solve the customer’s problem (like the customer’s most recent contact information)

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

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:

• Label (the name of the module)

• Advanced Query

• Use First Result

• Database

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. 

• For Salesforce connections, Salesforce has documentation of objects it makes available for query. For example, the screenshots below use the Contact object, which store contact information in Salesforce.

• For custom database connections, the Object dropdown will show all of the tables on your database. Refer to your organization’s documentation on these tables.

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

• Object Field

• Operator

• Type

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.

• The Object Field dropdown is the data value on the database you want to compare against.

• The Operator dropdown is the type of evaluation you want to make.

• The Type dropdown is the type of system value you want to use in 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:

• The Object Field set to nameFirst (the column on the database containing the employee’s first name)

• The Operator is set to = (we want the value we’re searching to be the same as the value in the database)

• The Type is set to Advanced (we want to provide a custom value to search)

• The Value is set to Stefan (this is the Catalyst Character we’re searching for)

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:

• The Object Field set to nameFirst (the column on the database containing the employee’s first name)

• The Operator is set to = (we want the value we’re searching to be the same as the value in the database)

• The Type is set to Advanced (we want to provide a custom value to search)

• The Value is set to Bennie (this is the Catalyst Character we’re searching for)

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:

1. Make the Look Up query more specific. For example, we could have queried where nameFirst is Bennie and nameLast is Franks. To do this, you'd use the +Add button in the Query section.

2. Route the Look Up module to another Look Up module to drill down to the correct record. For example, the next Look Up module could check the location value in addition to the nameFirst value.

3. Toggle Use First Result to be on. When you toggle this on, the Look Up module will use the first value it finds that meets the search criteria.

No matches

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

• The Object Field set to nameFirst (the column on the database containing the employee’s first name)

• The Operator is set to = (we want the value we’re searching to be the same as the value in the database)

• The Type is set to Advanced (we want to provide a custom value to search)

• The Value is set to John (this is the Catalyst Character we’re searching for)

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:

• There are no matches on the database OR

• The query has been set up incorrectly and can’t find the data you’re intending

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

1. Make sure the Look Up module is searching for the correct type of data.

2. Route the Look Up module to another Look Up module to search for an alternate field.

3. Route to a human. If the Look Up module is part of an automated data collection system, you may need a queue user to collect the information over the phone to search.

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).

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

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.

• Label: The Label field is where you can give a customized name to the workflow module.

• Save: Press the Save button to save any changes to the module.

• Advanced Query: Toggle the Advanced Query field on to gain access to custom SQL / SOQL queries.

• Use First Result: Toggle the Use First Result field on to instruct the Look Up module to use the first matching result it finds.

• Database: The Database dropdown menu is where you select the kind of database you want to query.

• Connection: The Connection dropdown menu is where you choose the specific database connection you want to use.

• Object: The Object dropdown menu is where you choose the table you want to query.

• Object Field: The Object Field dropdown is the data value on the database you want to compare against.

• Operator: The Operator dropdown is the type of evaluation you want to make.

• Add: The Add button lets you add more fields to queries or variables to return

• Trash can: The Trash can icon removes a query or a returned field.

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.

• Linked IDs: For values from Salesforce, Zendesk, or a Custom Database

• Advanced: For custom values and targeting advanced variables on an interaction.

• Source: Contains data associated with the customer, like:

  • • Phone Number

    • Email

    • Person Id

    • Person Device Id

    • Person Session Id

• Details: Contains various data values associated with the input, including:

  • • Tags

    • Comm Type

    • Recordings

    • Agent Recording

    • Caller Recording

    • Result

    • Notes

    • Points

    • Type

    • Queue

    • Contact Card URL

    • Avaya.cx User Email Address

    • Avaya.cx User First Name

    • Avaya.cx User Last Name

    • Avaya.cx User Full Name

    • Salesforce User Id

    • Zendesk User Id

• Routing Details:

  • • Inbound Number

    • Inbound Number Name

    • Channel Key

    • Email

• Comm Type

  • • Phone

    • Messaging

    • Video

    • Email

    • Task

• Variable: This can be any custom variable name that you can use later in the workflow. For more information, see: Overview: Variable replacement in workflows