Salesforce Prompt Builder Data Providers: Apex, Flow and Merge Fields

A prompt template is not a saved prompt. It is a recipe. Nothing is stored pre-filled - the prompt that reaches the model is assembled server-side from live data every time it runs. Data providers are how that data gets in.

What is a data provider in Prompt Builder?

A data provider supplies the values that replace the placeholders in your prompt template. Without one, the template is static text and the model has no idea which record it is talking about.

Salesforce calls the process dynamic grounding: placeholders are replaced with page context, merge fields and related records before the prompt is sent. That is what makes one template reusable across an entire org instead of writing one prompt per record.

What are the three types of data provider?

Merge fields are the default and the cheapest. Reach for Flow or Apex only when the data is not already sitting on the record or one hop away from it.

How do you ground a prompt template with Flow?

Flow-based grounding uses a specific Flow type, not an ordinary one.

1. Create a Template-Triggered Prompt Flow. It has to be this type, because it is bound to the template capability - that binding is what makes the template inputs available inside the Flow.
2. Do the work: query records, loop, calculate, call out to whatever you need.
3. Return the text using the Add Prompt Instructions element. That element appends your computed text to the prompt.

The Flow does not return a variable that the template then reads. It adds instructions to the prompt itself. That distinction is the thing most people get wrong on their first build.

When should you use Apex instead of Flow?

Use Apex when you need something Flow genuinely cannot do:

• A callout to an external system whose response shapes the prompt
• Logic that Flow would express badly, such as heavy loops or intricate string manipulation
• Reuse of an Apex service you already trust

Otherwise use Flow. It is inspectable by admins, and the person debugging a bad prompt at six in the evening is more likely to be an admin than a developer.

What are dynamic prompt actions?

Dynamic prompt actions is shorthand people use for grounding that computes something at run time rather than reading a stored field. In practice that means the Flow and Apex providers above, as opposed to plain merge fields.

It is not a separate feature with its own setup screen. If you are searching for it, the Template-Triggered Prompt Flow route described above is almost certainly what you are looking for.

Common questions

Do I need Data Cloud to use data providers? No. Merge fields, Flow and Apex all work against standard CRM data. Data Cloud is one source that a Flow or Apex provider can reach, not a prerequisite for grounding.

Does the prompt template store the grounded data? No. The template stores the recipe. Salesforce assembles the prompt server-side on every call, so the data is always current at run time.

Should I use Flow or Apex for grounding? Flow unless you have a specific reason not to. Apex is the right choice when you need an external callout that shapes the prompt, or logic that Flow would express badly.

Where GPTfy fits

GPTfy runs prompts against your own model through your own key, inside your org, on the same Salesforce data model. If you have already built grounding with Flow or Apex, that work is not wasted - the grounding pattern is identical; the model endpoint is yours.