Omni Flows Pilot Spoiler Alert [2/3]
Hello! If you’re coming from the previous article on OmniFlow Pilot Queue Based Routing: Thank You! If not, you might consider checking that guideline out. Or watch the video summary for it to catch up and understand where we’re coming from.
What are we doing here? Well, I’m taking you for a quick spin and showing you some of the things we’re bringing forward in our Omnichannel+Flow Pilot which I am showcasing specifically for Salesforce Chat.
Important mention: What I’ll show you here belongs to the roadmap and pilot capabilities realms which means that Salesforce’s Forward Looking Statements and Safe Harbor applies from now onwards and as you go about reading this, the previous and the following related article. This story is the second of a series of 3 article-guidelines in which I will present this compelling project.
VIDEO SUMMARY [6min]
SKILL BASED ROUTING [SBR]: CREATE A NEW FLOW
Let’s create a completely new flow. And this time, instead of doing queue based routing we will do skill based routing. Let’s do the same thing that we did before in the second scenario on the first article: let’s grab the contact. Remember to define your resources, input variables first. If this is sounding somewhat newish to you, please go back to the previous article and see how we configured these artifacts over there.
Do you have your recordId (text) and input_record (record) variables? Great. This time we need to add a new one which we will call “skillList”. This can be named anything you want it to be. Here’s how it needs to be configured: record variable, reference to the Skill Requirement Object, allow multiple values, and make it available for both input & output.
On that list is where we’ll store [and make use of] the different skill requirements we’ll need in our upcoming scenarios. This will be a record-variable with multiple values allowed for different ‘skill requirements’. In short, you’ll use it to define a list of skills, and then you’re going to add one or many skills to it.
In no time we will add one, which will be a ‘Chat Skill’. Thx for reading further along!
Fantastic. Let’s then grab the contact [as shown in previous instructions], and, we’re also going to get the case because we know that the embedded service / pre-chat form gives it to us. It is actually creating a case that comes-off the subject field in the pre-chat form. We know there will be a subject [provided by the customer] and we’ll leverage that.
Now, let’s make our Flow require a ‘Chat Skill’ for every chat: drag and drop an “Add Skill Requirement” action and choose the Skill: Chat Skill. The important step comes here: pass in as both input and output the skillList record variable we created earlier. At this moment in time, every chat that comes in will need that skill.
Let’s add a little bit of logic. Remember our case? We will make a decision that checks if its subject contains the word ‘order’. And if that’s the case (pun intended 🤓) then, it will also need an Order Skill. Expressed differently: if the customer wants to chat about an order then we’ll add in the Order Skill to our list of skill requirements. And we will be passing it in the skillList variable that we used earlier. Important: remember you need to pass it as an output as well. This is a necessary step. You need to make it both an input & output. That’s the way that this flow action works.
If it is about an order inquiry: it will require 2 skills, Chat & Order. Otherwise we’ll only need the chat skill requirement. Final step is to drag and drop a route-work action. Call it Route to skill, set input variable recordId, but this time, we’re going to go to Route To Skills instead.
Notice that I’ve selected “define skill requirements”. This is where we pass in that list of skills we’ve created earlier. And now we need to reference a routing configuration for this. We can leverage the one we created earlier in the first article.
[Note: Why needing to define a routing configuration for SBR? The reason for this is that a routing-configuration with queues is actually defined on the queues itself. But with skills you can dynamically define it. A routing-config specifies things like the size, weights and priority for the work being routed.]
Back to our Flow. Connect properly all nodes as shown below and you’re done! Recap: if the customer wants to chat about orders [or, as another example, has a technical problem]: it will require the Chat and the Order [or Technical] Skills. If not, it will just require the Chat Skill. And there goes our SBR scenario.
WHY 3 OPTIONS FOR SKILL REQUIREMENTS?
You probably noticed that there are 3 options for skill requirements when configuring a Route Work action with routing type “route to skills”. And these are Define Skill Requirements, Run Skills-Based Routing Rules, or Both. We used the first option.
What are Run Skills-Based Routing Rules, and Both for then? Let’s look at Run-Skills Based Routing Rules. Why or When would I used this one?
A UI for defining skill requirements is available in the set up experience today, let’s take a look at that. You’ve likely seen it and even use it. This should be the place where you can define a large number of delineated “if / then / else” type of logic for a given “Channel Object” such as Chat or Case for skill based routing rules.
Let’s illustrate this on a well known and used entity, the Case Object. The idea is that if you’ve got a large numbers of skill rules that are on the ‘channel object’ itself, you can just defined them in this UI and call them into the Flow. That may help you reduce the complexity in the number of decision nodes that otherwise you would need to do.
If you’ve got complex rules: then you can build them on the flow but if it’s just a larger number of simple rules, via standard and custom fields on the object itself: you can pull them in from the Skills-Based Routing Rules checking that very box on skill requirements.
And that’s what those 3 skill requirement options correspond to: whether you’re going to define them on the flow itself, which is just a list of skills on the SkillRequirement Object, or whether you’re going to use them from the “skills mapping set up” from the UI we just mentioned, or you can combine both (run those ones and then add custom ones from the flow) if you wanted to do as well. All of that will work.
Voilà! Don’t forget to save. Bravo for getting this far!
IN A NUTSHELL
In this article we walked through the new Omnichannel Flow Pilot capability and created a Skill Based Routing scenario leveraging both the Route Work (route to skills) and Add Skill Requirement actions. Go to the next article if you want to see a few examples for Omni+Flow on Direct To Agent Routing and more or go to the previous article if you want to check Queue Based Routing as well. Thank you.
Important: Salesforce provides Omni+Flow to selected customers through a pilot program that requires agreement to specific terms and conditions. Omni+Flow isn’t generally available unless or until Salesforce announces its general availability in documentation or in press releases or public statements. Salesforce can’t guarantee general availability within any particular time frame or at all. Make your purchase decisions only on the basis of generally available Salesforce products and features.
Have questions? Feel free to reach out. Let’s connect on Twitter. I’ll answer DMs faster than emails. @lecharleslozano
