Get to Know Einstein Copilot

With the arrival of ChatGPT3 and the overall rise in public awareness and access to artificial intelligence (AI) comes an invitation to explore a novel form of the user interface (UI)—one that’s conversational. Instead of having to select specific elements or options, users can simply ask an AI tool anything like they would ask a human. While we’ve already seen some of this with smart devices like Alexa, which uses natural language processing (NLP) to determine what the user is asking, generative AI tools like ChatGPT3 also respond by generating a human-like response as opposed to a predetermined outcome. From start to finish, the interaction is modeled after a conversation.

For a longer discussion about the possibilities of conversational AIs, see our AI Research team’s post, If You Can Say It, You Can Do It: The Age of Conversational AI.

Einstein Copilot, your Salesforce conversational AI assistant

Einstein Copilot places this conversational model across your Salesforce Platform by providing a context-friendly assistant. For example, if you’re on a specific case record, Einstein Copilot will recognize that and even offer common suggestions like “summarize this record”—all based on the page you’re looking at. It’s an AI assistant with access to all of your enterprise data from the same location.

Need to ask about the case’s related account? Need to summarize a related list? Not a problem. Here are a couple of options Einstein Copilot gives you just based on the record being a contact.

And here, Copilot is giving a summary of that account.

You can see from this example that Einstein Copilot is summarizing Corette not only on her contact information but also on related data, including custom data like the Booking and Guest Review objects.

Standard actions, custom actions

The magic behind Einstein Copilot is its use of actions. When it gets a prompt, it processes that request to determine what the user is asking. It then refers to its library of actions to provide an answer. Einstein Copilot is capable of chaining those actions in order to generate a response. To see this action, we can use the Copilot Builder to look behind the scenes at what Copilot is thinking and how it chooses the actions it needs to work. Let’s take a look at the Builder interface.

For instance, let’s see what it looks like with one of the examples above.

Once Copilot realizes it needs to find related records, it knows it will have to use the ID of the current record to make that happen, and so it starts with an action to find that ID. Then, it hands the ID to another action that knows how to find those related records, and then finally formats that to the user.

All of the actions we see there are standard actions, or actions that are developed by Salesforce and released with Copilot. Salesforce will continue to research and develop new standard actions in the future. However, you don’t have to wait on Salesforce to have more control over how Copilot responds to your users. You can create your own custom actions to bring experiences tailored to your users’ needs.

Using Flow for a custom action

Let’s take a look at creating a custom action and how to leverage your existing Flow skills to do so. In this example, we’re using a custom object model where a contact has three custom fields that describe their interests. Those interests are mirrored in this fictional company’s main export, adventure expeditions. What if we wanted to give sales reps, customer support reps, and account executives the ability to recommend those expeditions based on their interests, and to do that whether they were looking at a support case, the contact, or the expedition?

The core of this will be a very straightforward autolaunched flow.

Walking through that, the flow:

1. Takes the ID of the contact.
2. Pulls the three fields to determine the interests.
3. Searches for related expeditions.
4. Hands off that array.

Now, we create a custom action and embed that flow.

First, create a custom flow action.

Choose Flow for the type, and then select your specific flow.

To create the action, add in descriptions and select the options to control it.

Finally, save and activate the action so that it appears in Copilot Builder, where it will show up first under “Copilot Action Library”. From there, move it to the current Copilot’s actions and it will be added to the possible actions Copilot can use to respond to a prompt. So now, if you ask Copilot to find experiences your contact will be interested in, you’ll see this:

The importance of descriptions

We all know descriptions are important for human-friendly interfaces. It’s great to know more about that custom field or report, or nearly anything on the platform. However, in this age of AI, descriptions are way more important. Did you notice how we didn’t have to tell Einstein Copilot much about the kinds of questions that could be asked to trigger our custom action? That’s because it knows how to process the request, but when it does that it pulls a lot of metadata—including descriptions (or instructions, depending on the interface).

Whenever you build out anything for AI, remember the importance of descriptions—they’re the lantern that lets the AI know it’s looking in the right direction. To learn more about writing effective descriptions and instructions for AI, read Get Started with Einstein Copilot Custom Actions.

The better the data, the better the AI

AI is only as good as the data it’s trying to leverage. Now more than ever, it’s important to ask about data cleanliness. An abundance of duplicate records, outdated records, incomplete records, etc., will only invite Einstein Copilot to respond with less than useful responses. Copilot doesn’t have any way to parse data as good or bad; it will consume and utilize anything it has access to.

The Einstein 1 Trust Layer

Speaking of access, how do we know that the enterprise data being leveraged isn’t being made to the public via AI models? Can we be sure that users aren’t being given access to data they shouldn’t normally see? Are responses being monitored for things like toxicity? Welcome to the Einstein 1 Trust Layer.

Key highlights:

1. Your enterprise data will not be seen, kept, or used by any model powering Einstein Copilot for training.
2. The same security layer that enforces field-level security on the platform is used by Einstein Copilot.
3. On the return, responses are audited and monitored for toxicity and the models are adjusted accordingly.

Availability and user adoption

Einstein Copilot is currently generally available (GA) to Unlimited, Enterprise, and Performance Editions. It requires an add-on in the form of Einstein for Sales, Einstein for Service, or the Einstein Platform. Refer to Salesforce Help for the most recent availability and contact your Account Executive to discuss pricing and licensing.

In terms of user adoption, treat Einstein Copilot like any other high-level project. Rolling out to a small feedback group first is ideal and may give insights into custom actions that could help users be successful. Learn more about use cases and best practices for prompts with Get Started with Einstein Copilot Custom Actions.

Speaking of success, once you’ve rolled out Einstein Copilot, check out Harness Einstein Copilot Analytics and AI for Organizational Success for more on how to monitor the usage of Copilot with your users.

Learn more on Trailhead

Ready to get hands-on with Einstein Copilot? Trailhead is here for you. Using a trial edition with Einstein Copilot enabled, learn how to Get Started with Einstein Copilot.