Prompt Builder is a generative AI tool in Einstein 1 Studio that allows you to create reusable prompt templates. Prompt templates are resolved into prompts and sent to a large language model (LLM), always going through the Einstein Trust Layer, to get a response. They enable generative AI capabilities in common Salesforce business workflows, such as email and field generation, record summarization, and other custom workflows.

Prompt templates can be securely grounded using data that is not part of the LLM training data to give the model more context and improve the accuracy of its responses. You can choose different types of data providers, like Apex, Flow, or merge fields, to add context to your templates. In this blog post, we’ll give you an overview of the different grounding techniques that you can use to add data to prompts without limits.

Prompt template types

When you create a prompt template, you first have to choose its type. The type determines the objects to which that template will be bound, and its inputs. These are the objects that you will be able to reference when grounding the template. The type also determines how you can execute or invoke prompt templates, i.e., their entry points (we’ll cover executing prompt templates in a future post). The table below summarizes the four different template types currently available, along with the inputs and entry points for each of them.

Data providers for grounding

When executing a prompt template, data providers can use any of the inputs (or related records) to compute text, which is then added to the prompt that is finally sent to the LLM.

Note: Some features represented in the diagram above are currently being developed.

In simpler cases, you’ll reference the input properties directly on the template through a merge field or related list data provider. However, in some cases, you’ll craft more complex pieces of text to add to the template with the help of Flow or Apex.

When using the merge fields and related list data providers, you can reference data that comes from the CRM and from Data Cloud (using the Data Cloud enrichment feature when the input is a Contact or a Lead). When using Flow or Apex as data providers, you have full flexibility and you can reference data that comes from anywhere, including the CRM, Data Cloud, and external data sources.

* Data Model Objects (DMOs) and Data Cloud data graphs will be available soon.

Because this post is written for developers, let’s next focus on Flow and Apex grounding.

Grounding prompt templates with Flow

To ground a template with Flow, you’ll need to create a “Template-Triggered Prompt Flow” that’s bound to the template capability, so that the specific template inputs are available in the flow.

Once the flow is created, you can reference the template inputs as follows.

Then, once you compute the data to be added to the template, you use a new element called “Add Prompt Instructions” to add text to the template. You can use it as many ways as you need to as it’s additive.

Finally, in the Prompt Builder templates for which this flow was activated, you’ll be able to see and use the flow.

Grounding prompt templates with Apex

For grounding a template with Apex, you’ll need to create an @InvocableMethod and assign it to a capability type, the same as we did in Flow, but with code. The Apex code that you write will have to take into account the inputs that that template type is bound to. Let’s explore a sample invocable method that is made available for Sales Email templates.

Line 2: You assign the invocable method to a capability type. Capability types can be:

• PromptTemplateType://einstein_gpt__salesEmail
• PromptTemplateType://einstein_gpt__fieldCompletion
• FlexTemplate://template_API_Name, where template_API_Name matches the prompt template API Name field defined in Prompt Builder
• PromptTemplateType://einstein_gpt__recordSummary

Line 5: The invocable method’s parameter must be of List<Request> type. The Request class defines an @InvocableVariable member for each input defined by the prompt template. Refer back to the first table in this blog post to see which inputs are used on each template type.

The method needs to return an object of the List<Response> type containing a prompt invocable variable that will contain the data to be added to the prompt, once the template is resolved.

Line 7: In the method, you can access the inputs defined in the Request class and use them to compute the data that needs to be added to the template.

Line 14: Finally, you can craft the response, adding that data to the Prompt variable of the Response class.

Once your Apex class is deployed to your org, you’ll be able to use it in the Prompt Builder template types for which it was activated through its capability type.

When to use Flow or Apex for grounding will depend on your preference for using clicks vs code, the complexity of the logic to implement, and the guidelines that your company has for no-code vs code tools usage.

Try it out!

Prompt Builder requires an Einstein 1 Edition license, or it can be purchased as an add-on. You can try it out for free by requesting a five-day trial org as part of the new Quick Start: Prompt Builder module on Trailhead. As a bonus, Einstein Copilot will be included in the trial org as well. And if you want to know more, take a look at this comprehensive list of resources:

• Trailhead: Get Started with Prompts and Prompt Builder
• Documentation Prompt Builder
• Salesforce Admins blog post: The Ultimate Guide to Prompt Builder
• GitHub: Repo where you’ll find the examples shown in this blog

Interested in knowing what else Prompt Builder has to offer developers? Stay tuned, as in my next blog post, I’ll explain how to invoke prompt templates from Flow, Apex, and the REST API.

About the author

Alba Rivas works as a Principal Developer Advocate at Salesforce. You can follow her on Twitter or Linkedin.