The template type decides where the output can go, not how clever the prompt is. Sales email writes into an email composer, field generation writes into a field, record summary produces a summary of one record in a page component, and flex is the general one you call from Flow, Apex or an agent action. Pick by destination first. Everything else is the same job: assembling grounded text for a model.
The types, and the question each answers
Sales email. Bound to a recipient and a related record, and the output lands in an email draft a person edits before sending. Good when a human always reviews. The template type carries assumptions about salutations and signatures that you get for free and cannot fully escape.
Field generation. Produces a value for one field on one record. The output is short and typed, and the person sees it in place with an accept or reject step. Useful for a description, a summary field, a suggested category. Bad for anything a downstream process depends on being exact.
Record summary. Summarises a record and its related data for display, typically in a Lightning page component. Read-only by nature, which makes it the lowest risk of the set.
Flex. No assumed destination. You define the inputs, and it is invoked from Flow, Apex, an agent action or the API. If you are building anything that is not literally an email, a field value, or an on-page summary, this is the one.
The practical rule: if a typed template fits your destination exactly, use it, because the plumbing is already done. The moment you are fighting its assumptions, move to flex and accept that you now own the wiring.
Grounding with merge fields
A prompt template without grounding is a chatbot in a costume. Merge fields are how org data gets into the prompt text before it reaches the model.
You bind an input (a record, usually), and then reference fields from it in the template body. Related records are reachable through the relationship path, within limits that vary by template type and release.
Account: {!$Input:Opportunity.Account.Name}
Stage: {!$Input:Opportunity.StageName}
Close: {!$Input:Opportunity.CloseDate}
Amount: {!$Input:Opportunity.Amount}
Write two sentences for an internal deal review.
State only what the fields above support.
Three things are worth knowing about merge fields. They resolve with the permissions of the running user, so a field the user cannot see does not arrive. They resolve to blank rather than failing when empty, which is how a prompt quietly loses half its context. And they are static text by the time the model sees them, so a merge field cannot fetch anything the template did not ask for.
That last point is the honest limit of merge-field grounding. It is fine for one record and its immediate relations. It cannot search, it cannot rank, and it cannot pull the three most relevant documents from a library. That is what a retriever is for, and it is a different piece of the stack.
Where the output goes
Type by type: sales email into a draft, field generation into a field awaiting acceptance, record summary into a component, flex into whatever called it. The last one is where the care is needed.
A flex template called from Flow returns text into a variable. Whatever the Flow then does with that text is your design, and it is entirely possible to write generated prose straight into a record with no human in the path. That is legal and occasionally correct, and it should be a deliberate decision with a note explaining it, not a side effect of the Flow being easy to build.
Testing them properly
The builder’s preview runs against a record you pick and shows the resolved prompt alongside the response. Read the resolved prompt every time. Most bad output is a grounding failure, visible immediately as blank merge fields, and no amount of instruction rewriting fixes an empty field.
Test with an ugly record as well as a tidy one. Missing amount, no contacts, a description containing a paragraph a customer typed. The tidy demo record proves nothing.
Frequently asked
Can a template call Apex? Flex templates can take inputs supplied by Apex, and Apex-backed grounding has been expanding. What is supported varies by release, so check the current documentation before designing around it.
Which type does an agent action use? Flex, generally, because an agent action supplies its own inputs and consumes the returned text itself.
Does the Trust Layer apply to all of them? Masking, audit and retention behaviour apply to Salesforce’s generative features broadly. It does not decide which fields you merged in, which is the part that actually determines what leaves.
Why is the output inconsistent between runs? Because it is a language model. If you need the same answer every time, you need a formula, not a prompt.
