Salesforce Einstein Bots – Build Your Own Automated Salesforce Robot!

Share this article...

What are Salesforce Einstein Bots?

Salesforce’s Einstein Bots are automated chatbots that can be used for customer support or sales enablement. Whether you have a concerned customer with an issue or a browsing prospect wanting to know more about your products, Einstein Bots can provide a seamless experience with no interaction from your agents. Einstein Bots use NLP (natural language processing) to understand what your customers are typing and direct them to what they need.

Einstein Bots have been around since Summer 18’, but with the recent release of Winter 19’ they have become a whole lot easier to use, and more powerful than before. You can now use Flows to query Salesforce records and give the bot more information to work with.

Why should I use them?

There are a lot of benefits in using Einstein Bots:

  • Customers get an immediate response
  • The Bot can answer customer questions immediately, meaning less Cases get logged
  • Since the Bot can deflect easy cases, this gives your agents more time to work on more difficult cases
  • Bots can have personalised greetings to make your customers feel valued
  • Using NLP, bots can learn how to respond to customers appropriately

“Chatbots will power 85% of all customer service interactions by 2020.” – Gartner

How should I prepare to use them?

First figure out what you want to use the bot for, whether its customer service or sales enablement, or both. Then analyze what your target audience or customers ask most frequently. What are the most common cases that you get? What would you like your customers to be able to do without needing an interaction with an agent? Once you’ve analyzed this, you can begin to build out what you would like to use your bot for and how it’s going to help your customers and save your agents time.

What are the prerequisites?

Before you can start using Einstein Bots, there are a few prerequisites:

  • You must have a Service Cloud license and a Live Agent license
  • Omni Channel must be setup (Presence configuration, Routing configuration & Service Channel for Live Agent)
  • A Live Agent Deployment
  • Live Agent Chat button set to routing type: Omni-Channel
  • A Queue for your Chatbot agents
  • The agents must be Service Cloud users
  • A Snap-in Deployment to host the Einstein Bot

Once you have these prerequisites, you are ready to start using Einstein Bots! If you’ve never used Live Agent before, these prerequisites might seem quite intimidating and difficult to set up. Luckily, Salesforce provides a Live Agent Setup Flow that will set all this up for you! This can be found in “Service Setup”.

Let’s create an Einstein Bot!

Navigate to Setup, and search for Einstein Bots. Flip the switch to turn them on! (they can be deactivated again).

You also want to enable Live Agent Channel (this lets you relate the Einstein Bot to your Live Agent Chat button) and optionally enable the Bots Options Menu. This gives your customers the option to manually pick dialogs or let them transfer to an agent. Lastly, it’s always a good idea to log all your Einstein Bot conversations so you can debug them when testing and analyze them to see how your bot is performing.

Once you’ve done that, click “New” to launch the Einstein Bot creator. This will take you through the steps of creating a new bot; giving it a name, setting an initial greeting message, and specifying 3 initial menu items. Once you have done this you would think you could test your bot using the preview function, but it won’t work yet! There is one thing left to do: relate the Einstein Bot to your Live Agent chat button. Navigate to your chat button and specify the bot configuration like so:

Now you can preview your bot! Simply activate it and press preview. Select the snap-in channel and press submit. You will see the “Chat with an expert now” button appear. Click that and that chat will launch. If you used the Live Agent Setup Flow or didn’t customise your snap-in deployment, then a pre-chat page will appear. Fill in the required details and press submit – now you’re bot should start up with its greeting message! If you want to remove the pre-chat page you can do so by going into your snap-in deployment and deactivating the pre-chat page (this is also where you can specify that you want to capture Leads instead of Contacts).

Now we have a very simple but working Einstein Bot, let’s delve into the terminology to help you understand how to configure this beast.


If you’re a developer, you already understand what variables are, they aren’t much different from variables in Apex. If you’re not a developer, variables are used to store data, much like fields in Salesforce. The bot needs variables in order to store information gathered from the customer as well as information queried from Salesforce. It can then reuse that data to present it to the customer or query more records from Salesforce. In order to populate a variable, you can ask the customer a question and store their answer, or use flows & apex to get data from Salesforce. There are also some predefined context variables that the bot automatically populates when it is launched. One of these context variables is LiveAgentSessionId, which automatically stores the chat key of the Live Chat Transcript that gets created as soon as the bot is launched. We can use this to query that LiveChatTranscript and return information about the customer the bot is interacting with. Below is an example of some variables one might create:


Entities can be described as a wrapper for variables. They are like an additional data type. Salesforce provides standard ones (Text, DateTime, Date, Money, Number, Person, Location, Organization, Percent, Boolean, and Object) but you can create your own custom ones too using a regex pattern or a value list. Entities are only used when your customer is providing the bot with information. They can also be used as a form of validation, to stop your bot receiving “dirty” data. Let’s say we asked the customer for their email address; we can store this in a variable called “email” with a data type of Text. Then we can create a regex pattern Entity, using the regex of a standard email address. Then when the customer provides the bot with their email address, if they type anything other than an acceptable email address, they will be asked to try again.


Dialogs can be thought of like functions or methods that the bot jumps between during a chat. Each Dialog can optionally include Dialog Intents, which are phrases that your customers might use. The bot learns from Dialog Intents that you input yourself and then when it recognises one it initiates the corresponding Dialog. It’s within these Dialogs that you specify what you want the bot to do: Message, Question, Rule or Action. When the bot enters a Dialog, it will execute everything within that Dialog and then perform one of 4 actions at the end, one of either: ‘Wait for customer input’, ‘Show a menu’ (of Dialogs), ‘Start another Dialog’ or ‘Transfer to Agent’.


Messages are the most straightforward of the 4 nodes. The bot simply prints a message. Messages can also contain merge fields referencing Variables. For example, if you know the customer’s first and last name, you can store these in Variables and then reference them in a message:


Questions are used to gather more information from your customer. After asking the question, the customer’s response will get stored in a Variable. This is where you must also select an Entity to wrap your Variable. This brings us back to the email example we had earlier, if you wrap your variable in the email regex pattern entity, if the customer enters anything other than a valid email address, it will be rejected and the bot will ask them to try again.

To avoid invalid entries, you can also supply your customer with static or dynamic answers. Static answers are hard-typed options, whereas dynamic answers use Flows or Apex to query Salesforce and return a list of objects (such as Cases). The most interesting thing about questions is that you have the option for the bot to recognise the answer from the customer’s input. If the bot does recognise the answer it will save it to the variable without even asking the question!


Actions use Flows or Apex to get/update/delete data from Salesforce. They consist of input variables and output variables. For example; you could ask the customer for their email address and then run a Flow that finds that customer’s record from their email address and returns a list of all their open cases.

The biggest advantage of using Apex is that you can make callouts to external services using Salesforce’s REST API and store any data in the bots variables to reference later on. If you do use Apex, however, you must make sure to add the Apex class to the bots permission set (sfdc.chatbot.service.permset) otherwise it will not work!

In the above example, we can use the LiveAgentSessionId context variable to query the Live Chat Transcript record. When the bot is initiated, if the pre-chat fields are filled in with first name, last name and email, the bot will create a new Contact or find an existing one and link it to the Live Cha tTranscript. From here we can reference the Contact and assign the Contact’s fields to variables we want the bot to use (such as first name).


Lastly, we have rules. Rules are used to direct the bot down different paths into different dialogs if certain criteria are met. There are 5 rule actions:

  • Call Dialog – calls another Dialog, then the bot return to the original Dialog
  • Redirect to Dialog – redirect to another Dialog and the bot does not return to the original
  • Clear-Variable Value – clears a variable value, very useful for when your bot needs to ask a customer the same question
  • Transfer to Agent – transfers the customer to an Agent using LiveAgent
  • Pre-chat Form – currently does nothing

The above example shows how you can redirect to a different welcome dialog depending on whether or not the Flow successfully found the Contact, you don’t want your bot saying Hi {!FirstName}.


So to sum everything up, Einstein bots have somewhat of a low skill floor but a high skill ceiling, meaning they are fairly easy to get into and start building but are hard to master and can be designed to do some very complex processes. Focus on delivering what your customers are asking for or having the most problems with, and build on that as you and your bot learn more about their needs. Use dialog to set the flow of the conversation, variables to store the data your bot needs, intents to train your bot to understand what your customers are saying, and entities to safeguard against bad data.

6 thoughts on “Salesforce Einstein Bots – Build Your Own Automated Salesforce Robot!

  1. Hi!

    If I need to have a bot in both English and French, do I need to create two bots, (obviously two buttons) and two deployments (for both Chat and Embedded Service)?

    1. From what I know- you can only have Bots that use English. I am unsure of the Fact, that you can change the language to French. For “Dialog Intent” purposes, your Bot will only support English. This is regard to “NLP” and your Bots ability to learn from past interactions with your customers. Therefore, making your Bot more effective and you creating less Intent utterances to maintain it and keep your users happy. From the deployment stand point you would need to create a new one for each unique channel. So your Bots are accommodating your users as needed.
      (Bots have no Limitations…Essentially.)

      Thats from my understanding.
      Hopefully, I was able to help a bit.

      1. Thanks for the answers.

        I can see in one of your screenshots that you have an Email entity with a Regex pattern validation. Does that work for you? For some reason, in my case it either redirects to another dialog or ends the chat. Is there something I am missing?

Add Comment