Overview

Traditionally with Chat, there was a 1:1 relationship between the Chat Button and a Queue, so it was never easy to build dynamic routing logic in. If we wanted some chats to go to the sales team, and others to service, or if we wanted to prioritize VIP customers over others, we had to either use a Chatbot as a proxy, or code it into the pre-chat form somehow.

As of Winter ’22 though, it’s so much easier, with the launch of Omni Flows for Chat, and this post will help show us how to do that.

Two notes before we start, Omni Flow routing isn’t supported when using an Einstein Bot, though it is on the roadmap.

Also, make sure that you’ve read Build your first Omni Flow

Setup guide

We start off by building an Omni Flow. There’s a pre-built template for Chat or we can make it from scratch. The good thing about the template is that it gives an example of loading pre-chat data and using it to route based on that data.

Pre-chat data

When an Omni Flow is configured on a chat button, any customer inputs collected in the Embedded Service pre-chat form will be passed in automatically. If you’re not using the template, make sure to define an input variable of type Conversation Context Entry, with the ‘Allow multiple values’ checkbox selected.

Within the flow, you can loop over that collection, and check the Title (pre-chat field name) and Value (customer input) of each entry. This can then be used for whatever you need in the flow, linking the Contact, Creating a Lead or Case, or informing a Routing decision.

Decide where to Route the Chat

Once we’ve got the pre-chat data and loaded the Contact or other related information, we need to decide where to Route it.

The Route Work action will support us sending to a Queue, to a set of Skill Requirements, or Direct to a named Agent.

We can also set the Priority and Size of the Chat by changing the Routing Config or moving into a Queue with different values (allowing for us to escalate VIP customers to the front of the queue), and define what records will open when the agent accepts the chat via the Screen Pop action.

The below screenshot shows a simple example of a routing decision based on the subject in pre-chat, but we can ultimately define any logic that we want to (which is the great power of Flow, combined with all of the data about the Chat).

Add routing requirements to the Chat Button

Once we’ve built the Omni Flow, the last step is to map it to the Chat Button.
Now, if selecting the Omni-Channel routing type, you have the option to either provide a Queue (for simple scenarios) or to define an Omni Flow (for dynamic routing).

Update it by checking the box and selecting the Omni Flow that we just created, then we’re good to go. All new chats to this button will use that Flow to decide where to go!

Note: The go-forward routing type is Omni-Channel and we should use this for all newly configured Chat Buttons.

Extra notes

Heads up, when configuring the Flow from one of the templates, the Route Work actions are pointed to placeholder Channels, Queues, and Routing Configurations, and so you’ll need to swap these out for your own routing requirements before the Flow will work.

Overview

In Spring 22 there’s a massive leap forward in making the setup for Routing both easier and more powerful with the GA of Omni Flows for Service Cloud Voice (for Amazon Connect).

In the past, we needed to configure all of the Routing Requirements inside an Amazon Contact Flow. While an incredibly powerful tool, this comes with a few challenges that are resolved by moving the Routing Setup inside of Salesforce.

Some key benefits:

1. Configure routing rules for ALL channels in one place, inside Salesforce
2. Easily leverage Salesforce data and shared business rules in Routing requirements for Voice and other channels
3. Share all Voice Queue data to Omni Supervisor, and in general for Reports inside Salesforce

This Blog post is to get you a quick start in trying out, but make sure that you’ve read Build your first Omni Flow before going any further.

Setup guide

For more information on how this works under the covers, see Service Cloud Voice Routing – Technical deep dive. There’s a video version of this at the bottom of the post as well.

We start off by building an Omni Flow. There’s a pre-built template for Voice or we can make it from scratch. The good thing about the template is that it gives a simple but great example right from the start of the power that we get, where we can easily look up the Contact, and use data in Salesforce to drive the Routing decision.

Note: As inputs to the Flow, you should get in both the Voice Call record (with data on it like the customer phone number) and any custom IVR variables that you choose to pass in from Amazon.

Create the Queues inside Salesforce and Amazon

The key to making this work is mapping of the Queues. To do this, we create the queues in both systems (stay tuned for an upcoming release where we’ll be automating the Amazon part!).
There’s a simple 3-step process to do this.

Step 1: Create the queues in Salesforce
Create the queue the same way that you would any Omni Channel queue, but with a few key and critical notes to make sure:

1. Voice Call is the only object in the Queue
2. The Routing Configuration is marked as External Routing in the Routing Model field

Optional: If you want to report on it or see in Omni Supervisor, you should add users to the Queue. Note that currently this data isn’t used, as membership is defined in Amazon (step 2). Also note that Amazon doesn’t support adding individuals to queues, only groups (via Routing Profiles) so I’d recommend managing the membership via Public Groups to keep it easy.

Step 2: Create the queues in Amazon

As above, log into the Amazon Connect management console and configure the same queues.
Note that these queues are the master source for queue membership.

Step 3: Map the Queues in Salesforce

Inside Setup→Amazon Contact Centers, select your contact center and scroll down to see a few new sections. This first of these, Queue Mapping, allows you to add a new entry for each Queue.

Mapping the Omni Flow to the Phone Number

The last step to do is to define the Routing requirements for the Phone number.

Inside Setup→Amazon Contact Centers, for your CC, you can now add each Phone number as a Channel (exactly like how we setup SMS phone numbers in Messaging). Within that, we’re offered the option to either route all queues to a specific queue (for simple use-cases) or to define our Omni Flow created above. And that’s it! No need to configure anything more in Amazon, the system will automatically take care of it for us.

[Upgrade notes] for Voice Orgs created before Spring ’22 or without Omni Flows

If your Org was created prior to Spring ‘22, or didn’t have these new features enabled, then it’s likely that the routing rules are defined inside an AWS Contact Flow and you’ll need to make some small changes to get it working. Don’t fear though, we’ve made it really easy to do.

Just go into the Contact Flow, remove any existing routing logic (Transfer to Queue nodes), drag on the Subflow node, and point it to the new “Sample SCV Inbound Subflow”. And that’s it, no need to do anything else. We’ll cover in other posts how to pass in IVR data, but for now you should be good to go, Salesforce will use the details from the setup screens above to drive everything else.

Video walkthrough

A video guide of setting it up in an org.

So, you’re ready to build your first Omni Flow? Here’s a quick blog post to walk you through some of the basics. We’ll set up routing for a Case, but the fundamentals here will be true for other channels like Voice, Chat, SMS, Leads, Custom objects, or whatever you want to route.

In your Omni Flow, you’ll see we’ve exposed all of the Omni inputs as Actions on the left hand pallet. Now you’ll have complete flexibility to use any logic you like to determine what those inputs to the routing engine are, Queue/Skills/Agent, Priority, Size, you name it. Plus also, because it’s a flow, you can encapsulate all of your other business logic for the channel in here as well, like Creating a Case or linking the Contact.

You’ll also see some exciting new features that are only available in Omni Flow, like routing Direct to an Agent, or defining Screen Pop rules.

Either follow the steps below, or watch the video guide at the bottom of the post. Either way, you should be up and running in less than 10 minutes!

Create the Flow

Let’s start with the basics. There’s now a dedicated Flow type of Omni Flow to help you get started. (though some of the actions we’re about to see can be used in other Flows like autolaunched, record-changed, or screen flows).

Go to Setup→Flows, hit new Flow, then in All+Templates section create a new/blank Omni-Channel Flow.

Overview of the Actions

There are three key actions on the left hand-side (with more to come, and access to all other standard Flow actions)

1. Route Work – This is where you define the routing requirements:
   1. What Queue, Skills, Agent to go to,
   2. What the size or priority of the work is,
   3. etc.
2. Add Skill Requirements – Helps you to build up a list of Skill requirements for Skills-based routing
3. Add Screen Pop – Define what records will open on the screen when the agent accepts the work

Quick Guide

I’ll write other posts on more complex scenarios, but just to get you started we’ll show how to build a quick bit of Queue based routing logic. In this scenario we’ll check for some keywords in the Case.

Step 1: Define Flow input variables

Once created, you’ll need to define an input variable to get in the ID of the work item that you plan to route. Optionally, you can also pass in the record itself. These aren’t critical for Case routing as you could manually grab the ID if you wanted, but for the real-time channels like Voice or Chat they’re passed in and so you’ll need to define them to be able to use them later.

• recordId – type Text
• input_record – type Record

Step 2: Add some routing logic to the Flow

Let’s grab a decision node and check the Case subject. Here I made one that looks for some keywords like Billing or Tech Support.

Step 3: Route the work

Herein lies the fun part. Drag on the Route Work action where we’ll see a whole range of inputs to decide where we want to route the Case, and it’s priority.

Some key things to define:

• Record ID – this is the ID of the Work Item to route
  • use the recordId variable from before
• Service Channel – the object type that we’re routing
  • select ‘Cases’ or whatever you’ve named your Case Service Channel
• Route to – the type of routing you want to use (Queue, Skills, Direct to Agent)
  • select Queue here
• Queue – the name of the Queue that you want
  • Use the lookup and pick a Queue from your org to route to

Step 4 (last one): Invoke the Omni Flow

For real-time channels like Chat, Messaging, or Voice you can define the Omni Flow to run from their setup screens.

For other objects like Cases, Leads, or Custom-objects though you can invoke routing at any point, so here we’ll just use a trigger flow to kick it off whenever the case is created. Alternatively you might build a screen flow for transfer, or another record triggered flow to route whenever a customer re-opens the case. The world is your oyster.

We can kick off the Omni Flow as a sub-flow, just make sure to pass in the Case ID to the recordId input variable!

Finished

And with that, you’re good to go. Create a Case and test it. Then come back and share what you built, or read some other posts for more advanced scenarios like Skills-based routing, or the exciting new Direct to Agent routing options!

Video Guide