Prompt engineering, for admins

Salesforce handed administrators a genuinely new instrument over the last eighteen months. The Prompt Builder lets an admin design prompt templates that ground themselves on org data and produce text which lands in records, emails, and Agentforce conversations. The instrument is capable. The early work built with it mostly is not, and the reason is the oldest one in the field: a prompt is a program written in plain language, and a program missing half its logic behaves unpredictably. This is the primer we teach in workshops to admin teams new to building AI features.

01The five parts of a working prompt

Every prompt that does reliable work in production carries five parts. Different sources name them differently; the names matter far less than the discipline of including all five. Skip any one and the failure is predictable: drop the role and the output sounds generic, drop the constraints and it runs too long, drop the examples and the tone is uncalibrated.

02System prompt versus user prompt

Two terms that confuse newcomers. The system prompt sets the model up for the task and is written once, by the designer, applying to every interaction. The user prompt is what a person types or what an automation passes in at runtime. Role, task, constraints, and examples live mostly in the system prompt; context usually arrives in the user prompt because it is record-specific. The separation matters because the system prompt is your responsibility and stays constant, while the user prompt varies with every invocation.

03Grounding, done right

Grounding is the act of injecting real Salesforce data into the prompt so the model reasons over something concrete. The Prompt Builder does this with merge fields, the way an email template does. The mistake is to ground with everything. Pouring an entire account record into a prompt usually produces worse output, not better, because the model gets distracted. Ground with the fields the task actually needs. To summarise a case you need the subject, the description, the contact name, perhaps the last activity. You do not need the full history of the account.

A good prompt is the smallest amount of context that produces a reliable output. More is not better. Less is not better. The right amount is better.

04Patterns worth keeping

Refuse with a tag

If the prompt cannot do the task with the data available, it should not guess. Add a constraint: "If the description is missing, reply with the literal string MISSING_DATA and nothing else." The calling automation then routes appropriately, which beats the model inventing plausible content.

Structured output

When the result feeds downstream automation, ask for JSON. "Return a JSON object with keys summary, priority, escalation_needed." Models handle this well in 2026, and the downstream Flow parses each field and acts on it.

# SYSTEM
role: "You are a senior support triage assistant."
task: "Classify the case and draft a one-line next step."
constraints:
  - "Return JSON only."
  - "If Description is empty, set needs_info to true."
output:
  { "category": str, "priority": "low|med|high",
    "next_step": str, "needs_info": bool }

# USER (merged at runtime)
subject: {!Case.Subject}
description: {!Case.Description}

// a prompt template that produces machine-parseable output a Flow can act on, with an explicit escape hatch.

Hidden chain of thought

For complex tasks, ask the model to think before answering. "First list the key facts. Then draft a response. Then revise for tone. Return only the revised response." The internal reasoning improves the result without cluttering the user-facing output.

Tone through examples

The fastest way to a specific tone is to show two examples in the prompt. The model matches the style with surprising accuracy, and updating the tone later means updating the examples, which is cheaper than rewriting instructions.

05Test prompts like code

A prompt is a program, so test it like one. Build a small evaluation set of inputs paired with desired outputs, twenty to fifty examples covering the variety you expect. Run the prompt against the set, score the outputs, and when you change the prompt, re-run the set and decide whether the change is acceptable. The Prompt Builder has a testing surface; use it. Do not ship a prompt to production on the strength of three example outputs that happened to look fine.

06The trap to avoid

The trap is treating prompt engineering as creative writing. It is not. It is software design with stochastic outputs, and the discipline that makes a good engineer makes a good prompt engineer: precise specifications, small examples, fast feedback loops, and tests for the cases you care about. The model is your colleague and the prompt is the brief. A good brief produces good work. A vague brief produces a frustrating week, the same way it always has with any colleague.