Salesforce Prompt Builder

Watch a team demo a new AI feature in their org — a case summary, a generated email, a field that fills itself in — and then watch it six weeks later. Half the time it’s been quietly disabled, because it kept writing plausible things that were subtly wrong: a summary that missed the escalation, an email that named the wrong product, a field that confidently guessed. The instinct is to blame the model. The model is almost never the problem. The problem is the prompt and what it was grounded on, and both of those are decided in Prompt Builder — which most teams treat as a text box for typing instructions, when it’s really a data-binding surface that happens to have a text box in it.

Prompt Builder is the no-code authoring tool in Setup where you write, ground, version, and test the prompt templates that back everything from a one-click record summary to an Agentforce action. It’s the layer between “we have an LLM” and “the LLM says useful things about our data.” This post is what the template types actually are and when to use each, the grounding ladder from a merge field to a Data Cloud retriever, the Apex you write when the no-code picker runs out, and the ways a template drifts into fiction if you don’t test it like code.

What a prompt template is, and why it’s not just text

A prompt template is a reusable, versioned instruction to an LLM with grounding placeholders — spots where live Salesforce data is merged in before the prompt is sent. At resolution time, Prompt Builder assembles the final prompt: your instructions, plus the actual record values, related data, retrieved documents, whatever you’ve bound in. That assembled prompt runs through the Einstein Trust Layer — which masks sensitive fields, logs the exchange, and enforces zero data retention against the model — and the response comes back to whatever invoked it: a Lightning record page, a Flow, an Apex call, or an agent action.

A prompt template is a query with a sentence wrapped around it. The sentence is the part everyone edits; the query — what data you ground on — is the part that decides whether the answer is true. Spend your time on the grounding, not the adjectives.

Every template keeps a full version history, and activation is instant, which matters more than it sounds: it means you can iterate a live template and roll back a bad edit in one click. It also means an unreviewed edit ships the moment you activate it, so the version history is your safety net, not a suggestion.

The template types, and when each fits

Prompt Builder ships a small set of template types, and picking the right one saves you from bending a general tool into a specific job:

Field Generation returns an LLM response straight into a specific field on a record — a computed description, a risk note, a normalized value. It’s invoked from the field’s edit UI, from Flow, or from Apex. Reach for it when the output is a field value.
Sales Emails compose a personalized email grounded in record data — the classic “draft a follow-up to this opportunity.” Purpose-built for the compose-an-email shape, with the send flow already wired.
Record Summary produces a summary of a record and its context — the case-summary and account-brief use case, surfaced on the record page.
Flex is the escape hatch: any use case the others don’t cover. Unlike the fixed types, a Flex template’s inputs aren’t predefined — you define them yourself at creation and pass them in when you invoke it, which is what makes Flex the type that backs custom Flows, Apex callers, and agent actions.

For an agent, the template that matters is usually a Flex template wired to an action: the agent decides when to call it, and the template decides what data grounds the generation. That division — the Atlas reasoning engine chooses the step, the prompt template grounds it — is the seam where a lot of “the agent said something wrong” bugs actually live in the template, not the reasoning.

The grounding ladder

Grounding is the whole game, and Prompt Builder gives you a ladder of ways to do it, cheapest and simplest first:

Record merge fields. Pull values from the current record straight into the prompt via the resource picker — the contact’s name, the account’s industry, the opportunity’s stage. Perfect when the data you need is one field on the record in front of you.
Related lists. Bring in related records — the last few cases on an account, the open opportunities in a household — without writing a query. The reach of the merge picker, one hop out.
Flow. When the picker isn’t expressive enough, invoke a template-triggered prompt Flow that assembles data (with real branching logic) and merges the result back into the prompt. No code, more power.
Apex. When you need logic Flow can’t express — a transformation, an external callout, a computed value — an @InvocableMethod returns text that grounds the template. Full control, at the cost of code you own.
Data Cloud retrievers. The most powerful rung: ground on a Data Cloud data graph for a fast, pre-joined view of a customer, or run a RAG query against a vector-indexed corpus of documents via Intelligent Context. This is how you reach data that isn’t a field on the current record — unified profiles, contracts, knowledge.

The discipline is to climb only as high as the question needs. A field summary of the current case doesn’t need a Data Cloud retriever; a merge field does it. Reaching for the top rung when a lower one suffices is how you burn credits and context window on data the model didn’t need.

When the picker runs out: grounding with Apex

The Apex rung is where teams get stuck, so here’s the actual shape. You write an @InvocableMethod bound to the template’s capability type, take the inputs the template passes, and return the text to merge:

public class PropertyInterestPrompt {
    public class Request {
        @InvocableVariable(required=true)
        public Id contactId;
    }
    public class Response {
        @InvocableVariable
        public String prompt;   // text merged into the template
    }

    // capabilityType binds this method to the template it grounds — here a
    // Flex template by API name (fixed types use PromptTemplateType://...).
    @InvocableMethod(
        label='Contact Property Interest'
        capabilityType='FlexTemplate://Contact_Property_Brief'
    )
    public static List<Response> getInterest(List<Request> requests) {
        Id contactId = requests[0].contactId;

        List<Property_Interest__c> interests = [
            SELECT Region__c, Budget__c, Property_Type__c
            FROM Property_Interest__c
            WHERE Contact__c = :contactId
            WITH USER_MODE            // respect the running user's FLS/sharing
            ORDER BY CreatedDate DESC
            LIMIT 5
        ];

        List<String> lines = new List<String>();
        for (Property_Interest__c pi : interests) {
            lines.add(pi.Property_Type__c + ' in ' + pi.Region__c
                + ' up to ' + pi.Budget__c);
        }

        Response r = new Response();
        r.prompt = String.isEmpty(String.join(lines, '\n'))
            ? 'No recorded property interests.'   // never merge an empty hole
            : String.join(lines, '\n');
        return new List<Response>{ r };
    }
}

The capability type string is how the platform knows which template shape this method can ground — einstein_gpt__salesEmail, einstein_gpt__fieldCompletion, einstein_gpt__recordSummary for the fixed types, or a Flex template reference for a custom one. Two things earn their place in production code here: query WITH USER_MODE so grounding respects the running user’s field-level security and sharing (grounding is a data-access path, and a method that ignores FLS is a quiet leak), and keep the returned text tight, because everything you return is tokens the model pays to read.

Invoking a template from Flow, Apex, and REST

A template is only useful once something calls it. Field Generation and the record-facing types are invoked from the UI, but for programmatic use the entry points are:

Flow — the “Prompt Template” action runs a template and returns the response into a Flow variable, which is the no-code path most orgs standardize on.
Apex — call ConnectApi.EinsteinLLM.generateMessagesForPromptTemplate, passing the template’s developer name and an input object, and read the generated text off the response:

ConnectApi.EinsteinPromptTemplateGenerationsInput input =
    new ConnectApi.EinsteinPromptTemplateGenerationsInput();
input.additionalConfig = new ConnectApi.EinsteinLlmAdditionalConfigInput();
input.additionalConfig.applicationName = 'PromptBuilderPreview';

Map<String, ConnectApi.WrappedValue> params =
    new Map<String, ConnectApi.WrappedValue>();
ConnectApi.WrappedValue contact = new ConnectApi.WrappedValue();
contact.value = '003XXXXXXXXXXXX';
params.put('Input:contactId', contact);
input.inputParams = params;
input.isPreview = false;

ConnectApi.EinsteinPromptTemplateGenerationsRepresentation out =
    ConnectApi.EinsteinLLM.generateMessagesForPromptTemplate(
        'Contact_Property_Brief', input);

String generated = out.generations[0].text;

REST — the same generation is available over the Connect REST API, which is what you’d call from an external system that isn’t in Apex.

The Input: prefix on the parameter key matters — it maps to the input you defined in the Flex template. Get the key wrong and the merge silently returns nothing, which is the most common “why is my prompt blank” bug.

Test it like code, because it drifts

The reason AI features get switched off is drift — the template that worked on the record you tested and quietly fails on the ones you didn’t. Prompt Builder has the tool to catch it, and teams skip it: the preview and resolution panel. Preview runs the template against a real record and shows you the fully assembled prompt — every merge field resolved, every grounded value in place — before it goes to the model. That resolved view is the single most useful thing in the tool, because it turns “the AI is wrong” into “look, the merge field for the escalation was empty on this record, so the model never saw it.”

Test the way it’ll fail, not the way it’ll pass:

Empty fields. A merge field on a null field resolves to nothing, and the model fills the gap by guessing. Test records where the grounded fields are blank and see what the model does with the hole.
Adversarial records. The account with 300 related cases (does your related-list grounding blow the context window?), the contact with a name that reads like an instruction (does it survive the Trust Layer’s handling?), the record in a different language.
Re-test after every edit. Because activation is instant and unreviewed, a one-word change to an instruction can shift behavior across every record. The version history is there to roll back — use it, and treat template edits like code changes, with a review and a test, not like editing a doc.

Where Prompt Builder stops

It generates; it doesn’t reason in steps. A prompt template is one grounded call to a model — assemble context, generate, return. It does not plan, loop, or decide which action to take next; that’s the agent’s job via Atlas. A template is a building block inside an agent action, not a replacement for one. If your problem needs multiple steps and decisions, you want an agent that calls templates, not a bigger template.
Grounding doesn’t guarantee obedience. Feeding the model the right data makes a right answer likely, not certain — the LLM can still ignore an instruction or over-summarize. For outputs that must be exact or structured, validate the response after generation rather than trusting the prompt to have enforced it.
Every rung of the ladder has a cost. Data Cloud retrievers and RAG grounding consume Data 360 credits on top of the model call; over-grounding — returning more related data than the answer needs — inflates both the token bill and the odds the model latches onto the wrong detail. Climb the ladder only as far as the question requires.
The Trust Layer protects the transit, not your design. Masking and zero-retention govern what reaches the model; they don’t stop you from grounding a template on a field the running user shouldn’t see. Query WITH USER_MODE, and scope what each template can reach.

What to actually do

If you have AI features in your org that people don’t quite trust, open the templates behind them and look at the resolved prompt on a hard record — the drift is almost always visible there. Pick the narrowest template type that fits the job, and climb the grounding ladder only as high as the question needs: a merge field before a Flow, a Flow before Apex, Apex before a Data Cloud retriever. Ground with FLS respected, keep returned context tight, and test against empty and adversarial records, not just the clean one from the demo. Treat every template edit as a code change with a review and a roll-back plan, because activation is instant. Do that and the LLM stops being the thing you blame — because you’ve made the part that actually decided the answer, the grounding, something you can see and test.

The teams whose AI features survive contact with production aren’t running better models. They’re running better-grounded prompts, and they found that out in the resolution panel before a customer did.

Understanding the basics

What is Salesforce Prompt Builder?

Prompt Builder is a no-code tool in Setup for creating, grounding, versioning, and testing prompt templates — reusable instructions to an LLM with placeholders where live Salesforce data is merged in before the prompt is sent. It supports several template types (Field Generation, Sales Emails, Record Summary, and Flex for anything else), runs every generation through the Einstein Trust Layer, and lets templates be invoked from the record UI, Flow, Apex, the REST API, and Agentforce agent actions. It’s the layer where what an AI feature actually says about your data gets decided.

How do you ground a prompt template in Salesforce data?

Prompt Builder offers a ladder of grounding methods, simplest first: record merge fields (values from the current record), related lists (related records without a query), Flow (a template-triggered prompt Flow that assembles data with logic), Apex (an @InvocableMethod returning text, for logic Flow can’t express), and Data Cloud retrievers (a data graph for a pre-joined customer view, or a RAG query against vector-indexed documents). Use the lowest rung that answers the question — over-grounding costs credits and context window and raises the odds the model fixes on the wrong detail.

How is a prompt template different from an Agentforce agent?

A prompt template is a single grounded call to a model: assemble context, generate a response, return it. An agent reasons in steps — it plans, decides which action or template to call, loops, and can take governed actions — using the Atlas engine. A prompt template is a building block inside an agent action, not a substitute for the agent. If your task is a one-shot generation (summarize this, draft that, fill this field), a template is enough; if it needs multiple decisions and actions, you want an agent that calls templates.

Have AI features your team doesn’t trust, and not sure whether the fix is the prompt, the grounding, or the data underneath? Talk to us — building grounded prompt templates and the agents that call them, so they hold up on the hard records, is exactly the work we do.

Salesforce Prompt Builder: grounded prompt templates that don't drift into fiction