Automate This! — Power Up Your Einstein Bot with Flow

Hey everyone, I’m Kristi, a Salesforce MVP and Senior Consultant at Slalom. I’ve been in the Salesforce ecosystem for about 11 years, and I basically just identify as a Salesforce nerd. I lead the Salesforce San Diego Community Group and am also a Tableau Ambassador! I eat and drink automation, and I’m so happy to be able to share some great stuff with you today! The solutions I’m going to walk you through were all part of a really cool project to power up an Einstein Bot and provide a better experience for end users.

The first use case is one that a lot of service managers will relate to. Maybe you know there’s an event happening, and you’ve got a sudden influx of chats and need a way to quickly get the word out that you know this thing is happening. Of course, there are other methods of doing this—like a banner on the support website, for example—but does that keep people from initiating chats? Nope! With a custom object and the power of Flow, I was able to give my service managers a way, that they could control, to have the Einstein Bot deliver a message at the beginning of the chat and then ask the user if that’s why they were coming by or not.

The Announcement object to manage the chat message

First, I created a very simple custom object called Chat Bot Announcement. In this object, I needed a place for the service managers to be able to type out their message, so I added a long text area called ‘Announcement’. Easy, right? I also realized that these service managers are really busy, especially when there’s an event, so I knew they wouldn’t have time to come back to this announcement and turn it off later. So, I also added Start Date/Time and Expiration Date/Time fields so they could set the time period they want their message to show. And lastly, I created a formula field called ‘IsActive’ that compares the current time to the times in the Start and Expiration fields to see if we’re in between those times.

Super simple: one object, four fields, and so many happy service managers! We’re not done yet, though—now comes the flow!

The pre-context flow

If you’ve ever built an Einstein Bot, then you know about the pre-context flow and how powerful it is. Behind the scenes, when a chat is initiated, there’s some code that runs that tries to match the end user with a Lead, Contact, or Case, depending on the context you’ve chosen for your service deployment. If it doesn’t find one, it creates a new one for you. The pre-context flow then takes that found or created ID as an input so that you can do cool things with it. This flow also takes the newly created Chat Transcript ID as an input. Here’s what it looks like out of the box:

So, why am I telling you about this pre-context flow when we were obviously talking about the Chat Bot Announcement object? Because I added functionality to this same flow that checks for an active Chat Bot Announcement record at the same time it looks up other things, like who my bot is chatting with. Using a Get Records node, I can search for any chat bot announcements where my IsActive flag equals True.

If we find one, I’m going to save a couple new variables. First, the ID of that Announcement which I also added a lookup on the Chat Transcript record that I can fill so that I can keep track of how many chats were shown my Announcement. And second, the actual Announcement value itself.

For my Announcement variable, I’ll be sure to check that little box to make this available as an output. And this is the key to using flows with your Einstein Bot: inputs and outputs! Because I’ve marked this variable as ‘Available for output’, I can now access it in my Einstein Bot!

And now in my bot, after my pre-context flow runs, I can add logic to see if my Announcement variable was filled. If yes, I’m going to redirect to a different dialogue that sends my Announcement as a message, and then additional logic to ask them if that’s why they initiated the chat, and move on from there.

With this one simple object and this one simple node in my flow, I gave my service managers the power to get a message out in the bot; empowered my customers to acknowledge that’s why they came so they don’t have to spend time waiting for an agent or explaining the issue; deflected all those would-be chats from my agents; and gave my service managers a reporting mechanism to see how many chats were initiated about that event. THAT’s the power of Flow and Einstein Bots!

The Omni-Channel flow

That’s pretty cool, but I’ve got another one for you. Let’s say I’m an end user and I want to speak to an agent. I select that menu option or get routed to a person based on other logic—but oh, no! No agents are available. As an end user, I just got really sad. Why did it bother getting my hopes up of talking to someone when no agents were online in the first place? It creates a bad user experience to waste someone’s time in this way. So, how do we solve for that? In that same pre-context flow, of course!

Since our pre-context flow is not an Omni-Channel flow, I can’t access things like the Check Availability action (which made me really sad when I was first building this out). But I discovered that I could launch an Omni-Channel flow as a subflow and call that action! To do this, I first need to create an Omni-Channel flow.

I add an action called ‘Check availability’ and then set its input values. My Service Channel is Chat, and I want to check availability for the queue that my bot is already routing to. I manually assign variables that I’ve checked as output, of course. I’m collecting the Estimated Wait Time and Number of Agents Online.

Next, I save and activate that flow so that I can add it as a subflow in my pre-context flow. (How many times can you use the word “flow” in a sentence?)

The subflow for the win

Since I made my variables in the subflow available as outputs, I can now access them in my pre-context flow. I add these values to other values I assign for my bot to use with an Assignment node and variables that are—you guessed it—available for output.

Back in my Einstein Bot, on my Transfer to Agent dialogue, I can use these variables to run logic. Now, when someone makes it to the Transfer to Agent dialogue, I can say something like, “We don’t have any agents online right now, would you like to perform one of these other actions instead?”

Or better yet, at the beginning of the chat, I could say something like, “We don’t have any agents online right now, but have fun talking with our bot, Robot Downey, Jr. He can help you open a case or do some other things.” So now, with just a quick one-node subflow, and a few more Output variables, I’m able to save someone time in their day and provide a better customer experience. How’s that for some Flow power?!

The Platinum SLA

Okay, last one, promise! Back to that Transfer to Agent dialogue. What if the person chatting shouldn’t be able to get routed to an agent at all because of their service-level agreement (SLA) or some other factor based on record information? What if I told you that I could control which dialogues people were able to get? I can! But how? You guessed it... the power of Flow.

This time, in my same pre-context flow, I’ll add a Decision node. And I’ll check to see if this contact has an active SLA by filtering on SLA Expiration Date is Greater Than or Equal to today.

If they have an active SLA, I’ll fill a variable with their SLA Level: Platinum, Gold, Silver, or Bronze. If they don’t have an active SLA, I’ll fill that variable as blank.

And remember, our variables need to be ‘Available for output’ so we can access them in the bot!

So now, with one Decision node and an Assignment, we’ve powered up our bot even more. Now I can run logic like, for example, if this person has a Platinum SLA, I’m going to send them a different welcome message. If this person has a Bronze SLA, I’m going to make sure they don’t see any menu options that would transfer them to an agent, since that isn’t included in their SLA. In the real version of this implementation, I was able to implement seven different playbooks based on customer type and SLA that drove the logic for different menus, messages, and rules that fired. And that is a powerful experience!

That was a lot, I know—three amazing use cases solved by just one flow that I was already running as part of my bot! That’s the power of Flow, Einstein Bots, and thinking outside the box.

Resources

• Trailhead: Einstein Bots Basics
• Trailhead: Einstein Bots Project Planning
• External Site: Force For Fun: Service Cloud Blog Posts

Want to see more good stuff? Subscribe to our channel!