AI in Salesforce: Agentforce and Einstein

You have used chatbots like ChatGPT or Gemini. Now imagine a chatbot that lives inside your company's Salesforce org: it can look up a customer's order, check a refund policy, update a Case and hand over to a human when it gets stuck. That is the idea behind Agentforce, Salesforce's platform for building AI agents.

This lesson explains the ideas, the vocabulary and where you fit in as a Salesforce admin or developer. Salesforce changes the names and screens of its AI products often, so treat the product names here as a snapshot and confirm them on Salesforce's own pages and Trailhead.

Einstein was the name Salesforce gave to its AI features from around 2016. Early Einstein was mostly predictive AI: models trained on your own data that predict a number or a category, for example how likely a lead is to convert. It also included features such as Einstein Prediction Builder and lead scoring. Predictive AI is still useful: it answers "what will probably happen?".

Generative AI (large language models) arrived in Salesforce later. It writes text, summarises a long Case history, drafts an email reply and answers questions in natural language.

Agentforce is the platform where generative AI does not only answer, it also acts: it decides what to do and uses tools to do it. If you have read the AI Engineering material in Tech Tracks, this is the same agent idea (a model that plans and calls tools), packaged inside Salesforce with your data and security around it.

An agent in Agentforce is built from a few parts. Learn these words, because every interview question about Agentforce uses them.

The loop is simple. The customer writes a message. The reasoning engine picks the matching topic, reads its instructions, decides which actions to run, runs them, and writes a reply based on the results. If nothing fits, or the rules say so, it escalates to a human.

An action is how the agent touches the rest of Salesforce. Actions can be built from things you already know:

This is why the earlier lessons matter. A company that cannot build good Flows, Apex and secure data access cannot build a good agent either. Here is a sample of an Apex action. The annotation @InvocableMethod makes the method visible to Flow and agent tools. The label and description matter: the AI reads them to decide when to use the action, so write them clearly.

public with sharing class OrderStatusAction {

    public class Request {
        @InvocableVariable(label='Order number' description='The customer order number, for example BB-1042' required=true)
        public String orderNumber;
    }

    public class Result {
        @InvocableVariable(label='Status' description='Current status of the order')
        public String status;
    }

    @InvocableMethod(label='Get order status' description='Finds an order by its order number and returns its current status')
    public static List<Result> getStatus(List<Request> requests) {
        // Bulk-safe: one query for all requests
        Set<String> numbers = new Set<String>();
        for (Request r : requests) {
            numbers.add(r.orderNumber);
        }
        Map<String, String> statusByNumber = new Map<String, String>();
        for (Case c : [SELECT Subject, Status FROM Case WHERE Subject IN :numbers]) {
            statusByNumber.put(c.Subject, c.Status);
        }
        List<Result> results = new List<Result>();
        for (Request r : requests) {
            Result res = new Result();
            res.status = statusByNumber.containsKey(r.orderNumber) ? statusByNumber.get(r.orderNumber) : 'Not found';
            results.add(res);
        }
        return results;
    }
}

This sketch uses Case.Subject as a stand-in for an order number. A real project would have an Order object. Notice the input and output are lists, as invocable methods require.

Companies worry about two things: leaking private data to an AI model, and an AI saying or doing something wrong. Salesforce answers with the Einstein Trust Layer, a set of protections between your org and the language model. In Salesforce's description, it includes masking of sensitive data in prompts, agreements with model providers about not keeping or training on your data, checks for harmful content, and an audit trail. Read the current Trust Layer page for exact features, because they develop over time.

But the platform cannot do everything. Your design choices matter:

Permissions. An agent should have only the access it needs, using the same profiles, permission sets and sharing rules you learned in *Security model: profiles, permission sets and sharing*.

Grounding. Give the agent real data and policies (knowledge articles, records). An agent that is not grounded will guess, and language models can state wrong things with confidence.

Boundaries. Write instructions that say what the agent must not do, and send risky cases to a human.

Testing. Test with many realistic and tricky messages before going live, including rude users, vague questions and attempts to trick the agent into breaking its rules. Salesforce provides testing tools for agents; check the current documentation for what is available.

An agent is only as good as the data it can reach. Salesforce's data layer for bringing many sources together (known as Data Cloud; Salesforce has been renaming its data products, so check the current name) can unify customer data from the CRM, a website and other systems so that an agent sees the whole customer. Knowledge articles and clean, well-structured records improve answers. If your data model is messy, the agent will be confused too. This links back to *Data model: objects, fields and relationships*.

A useful way to pick a first use case: choose a task that is frequent, rule-based and low risk, such as order status questions or password help. Measure results (for example, how many chats were resolved without a human and whether customers were satisfied) and improve in small steps.

I work as a Salesforce [admin/developer] at a [type of company]. Design a first Agentforce agent for [use case, for example answering order status questions]. List: 1) three topics with one-sentence instructions each, 2) the actions each topic needs and whether to build them as Flow or Apex, 3) the data the agent needs, 4) what it must never do, 5) when it must hand over to a human, 6) 10 test messages including 3 tricky ones. Keep it short.

What to expect: Look for a small scope, clear boundaries and a human handover. Remember it is a design on paper: nothing here has been checked against your org.

How this comes up in interviews. Expect questions such as: What is the difference between predictive and generative AI? What are topics, instructions and actions? How would you make an agent safe? How would you build an action that looks up data? Strong answers name the parts, mention grounding, permissions and a human handover, and give a concrete small example like the one above. Weak answers just say "the AI will handle it".

To practise for free, look on Trailhead for the current Agentforce trail and for Developer Edition orgs that include Agentforce features. Availability and limits can change, so check the Trailhead pages. If you want a certification later, the exam is called Salesforce Certified Agentforce Specialist (see *Salesforce careers and certifications*).