A Prompt Builder template behaves like production configuration. Change one and a customer email, a generated field or an agent’s answer changes with it, sometimes without a release anyone reviewed. The sponsor or the admin owner does not need to write prompts. They need to know who owns each template, what it may read, how it was tested, who may change it, and what users are told about its output.
One owner per template, and one per grounding source
Each template needs a business owner for its output and an admin owner for its configuration. The sales operations lead decides what a Sales Email template may say; the service lead decides what a case summary contains. The admin owner holds the version, the permissions and the release.
Grounding data needs owners too. Every merge field, related list, Flow or Apex class that feeds a template is a dependency, and its owner is the person who knows whether that data is current. A template that pulls fifteen fields has fifteen dependencies. Ask for the list, and ask that each source be justified: it is added only when a test shows it improves a defined behaviour. Extra context also brings stale values, contradictions and wider exposure, and it does not improve the answer by default.
Keep templates single-purpose. A template that “summarises account history, suggests next actions and identifies risks” is three templates under one name. Split it, so that each part has one owner and one test set. Then record who consumes the output: a Flow, an action, a generated field, a page, an agent. A Flex template called by an agent ties the two together. Roll back the template without the agent configuration that calls it, or the reverse, and the behaviour stops matching what was tested.
What a template may read
When I teach ADX201, the security module rests on one idea: a user sees what their profile, permission sets and sharing allow. A template reads records on someone’s behalf, so the governing question is whose access it uses when it resolves its data. Ask for the answer per grounding source. A merge field, a Flow and an Apex class do not necessarily run with the same access, and a demo run by an admin will not show the difference.
Then test it. Run the template in a sandbox as a user who must not see a given field, and confirm the output does not reveal it. Keep a short list of fields that no template may merge, whatever the user’s access.
Watch where the output lands. A Field Generation template that summarises restricted notes into a field visible to more people republishes that content to the field’s audience. Once stored, the output follows the access rules of the field that holds it, whatever the rules of its sources.
A test set approved before release
A template goes live on a test set, and three good examples are not one. The set covers normal cases, empty fields, sources that contradict each other, a user without access, a request outside scope, sensitive content and attempts to override the instructions. For each case, store the input, the resolved context and the acceptance criteria: structure, allowed facts, mandatory fields, forbidden content. Several phrasings can be valid, so the criteria do not rely on word-for-word comparison.
The business owner approves the cases and expected results before the release, not after reading the outputs. A controlled refusal counts as a pass. A generated field that says “Not identified” when a call transcript names no pain point is a correct output, and a value someone can query later to find records that need a human look. A fluent answer with no basis is a failure.
Prompt Performance Metrics is documented as a beta feature built on Data 360 Calculated Insights, which can increase credit consumption. Treat it as telemetry next to the test set. It does not replace the release gate.
Versions, release cadence and who may edit in production
Every template change has an owner, a reason, a new version, a test run and a return path. Rolling back is more than restoring the previous text: identify the outputs stored and the actions triggered while the faulty version was active.
Align reviews with the release calendar the org already follows. Salesforce ships three releases a year, and a template that passed in spring can behave differently after the next release even if nobody edited it. I redo each course exercise before a session for the same reason. The test set deserves the same rerun after each release, not only after edits.
Production edits follow the path of any other metadata: change in a sandbox, test, deploy. Keep a short, named list of people who can create and edit templates. Running a template and editing it are separate permissions, and most users need only the first.
Einstein Trust Layer settings and what users are told
The Einstein Trust Layer settings apply across templates, so their owner is the platform owner and a change there goes through the same review. Ask to see them in Setup rather than on a slide, and check at least these points:
- data masking: which data types are masked before a prompt leaves Salesforce, and which features the setting covers;
- the audit trail: whether prompts and responses are stored, for how long, and who may read them;
- toxicity detection: whether scores are recorded, and who reviews the flagged outputs.
Users need to know what the output is and what it is not. It is a draft generated from named fields. It is not a verified fact, a commercial commitment or legal advice. Tell them what to check before saving or sending, and how to report a bad output so that it reaches the template owner. For customer-facing text, the person who sends it remains accountable for it.
What to check
- Does each active template have a named business owner and admin owner?
- Can the admin owner list every grounding source of a template and say whose access each one uses?
- Did the business owner approve the test set before the last release?
- How many people can edit templates in production, and are they named?
- When were the Trust Layer settings last reviewed, and by whom?
- Do users know what to check before they save or send an output?