What we learned creating fundraiser briefings with Salesforce Prompt Builder

Fundraisers spend a surprising amount of time preparing. Before a call or a visit they open several records, scroll through donation history, check whether anyone else in the organisation has been in touch, look for the last thing that was promised, and try to remember what matters to this particular person. It is careful, valuable work, and it is also fragmented.

The work asked a narrow question: could a Salesforce Prompt Builder field generation template assemble that preparation into a short, dependable briefing? In practice a fundraiser opened a supporter record, selected the generative AI action on a generative AI-enabled field, and Prompt Builder produced a draft briefing from grounded CRM data—record fields plus gift records retrieved by a Flow. It supported preparation. It did not act autonomously and it made no decisions.

This was designed and tested in UAT rather than run as a production service, so there are no performance figures to report. The useful output was a clearer understanding of what such a solution needs in order to be trustworthy.

What the solution was asked to do

The scope was deliberately tight. Given a supporter record, the generated briefing should:

• Draw on the relevant CRM information held about that supporter.
• Summarise donation and engagement history in plain language.
• Highlight relationships, recent interactions and any open actions.
• Read as a concise briefing a fundraiser can scan before making contact.
• Clearly separate what the CRM knows from what is missing.
• Never invent a fact, a figure or a recommendation the data does not support.

That last pair of constraints did more to shape the design than anything else. A briefing that says “no recorded contact in the last twelve months” is useful. One that produces a plausible narrative to fill a gap is worse than no briefing at all, because a fundraiser will act on it in front of a supporter.

Lesson one: one user, one job

The first version of any brief like this tends to sprawl: it should help fundraisers, and supporter care, and the events team, and produce reports. Each additional audience widens the data it needs and dilutes the output for everyone.

Choosing a single user—a relationship fundraiser—and a single job—preparing for one supporter conversation—made every subsequent decision easier to make and easier to test. Breadth can come later, from a foundation that works.

Lesson two: ground it in data you already trust

A generated briefing inherits the quality of its sources. Where donation records were clean and relationships well maintained, the outputs were more useful during testing. Where contacts were duplicated or activities logged inconsistently, the briefing faithfully reflected the mess—sometimes more visibly than a report would have done.

Lesson three: retrieval matters more than prose

It is easy to be impressed by fluent writing. The quality that actually determines whether a briefing is useful is what reached the model: the right records, the right recent interactions, the right open action.

Most of the disappointing early outputs were grounding failures wearing a confident tone. Evaluate what was supplied before you evaluate how it reads.

Lesson four: test the hand-off, not just each component

A Flow can return exactly the records you expect when you debug it on its own, while the resolved prompt receives a different or much larger set. That mismatch occurred during this UAT work, and it took a while to see because each component looked correct in isolation.

The lesson is to test the whole chain end to end: the record context the action runs from, the input mapping into the template, the Flow output, and the resolved prompt itself. Better prose instructions cannot correct the wrong input data.

Lesson five: access and execution context must be designed

A generated briefing must never become a route around access controls. If a fundraiser cannot see a safeguarding note, a restricted gift arrangement or another team's records in the CRM, the briefing should not summarise them either.

Do not assume the platform will settle this for you. Decide which data the template may use and the context it executes in, then test it deliberately—users at different permission levels asking for a briefing on the same record, and comparing what comes back.

Lesson six: shorter is more useful

Early briefings were thorough and largely unread. A fundraiser may have only a few minutes before a call. What they need is the relationship, the recent history, anything outstanding and anything sensitive—not a comprehensive account of every interaction since 2014.

Constraining the output to a handful of short, labelled sections made it dramatically more valuable. A gap stated plainly is part of that value.

Lesson seven: test the awkward cases on purpose

Testing only tidy supporters tells you very little. The cases worth constructing deliberately are:

• The expected case—a well-maintained record with clear history.
• Missing data—no recent contact, no giving history, incomplete details.
• Conflicting data—two records, contradictory preferences, disputed amounts.
• Edge cases—a legacy pledge, an anonymous gift, a supporter who has asked not to be contacted.

How the output behaves when the data is poor is a better guide to whether you should trust it than how it performs at its best.

Lesson eight: inspect the resolved prompt as well as the response

Prompt Builder's preview lets you inspect the resolved prompt—the data and instructions that actually reached the model—and compare it with the generated response. Reviewing both together is what turns anecdote into evaluation.

For Flow-grounded templates, test the Flow output and the input mapping separately as well. That is how you tell a retrieval or context problem apart from a prompt-writing problem, and the two need entirely different fixes.

Lesson nine: version it and watch it

Outputs can change when the prompt template, the Flow, the input mapping, the CRM data or the underlying model changes. Without controlled versions and a small recurring regression test set, you cannot tell whether last week's tweak improved things or quietly broke them. Treat it as a system with releases, not a setting.

Lesson ten: it prepares the fundraiser

The most important boundary is the simplest. The job is to help a person walk into a conversation better prepared. Judgement about what to say, what to ask for and when to hold back belongs to the fundraiser, who understands the relationship in ways no CRM records.

A checklist for a first internal prompt template

1. 01Name one user and one job it will do.
2. 02List the exact record data and Flow sources it may use, and confirm you trust them.
3. 03Decide how access and execution context will work, and test at different permission levels.
4. 04Define the output format, and keep it short.
5. 05Write the rule about missing data explicitly: state gaps, never fill them.
6. 06Build a test set covering expected, missing, conflicting and edge cases.
7. 07Inspect the record context, input mapping, Flow output, resolved prompt and final response—not just the wording.
8. 08Version every change and rerun the regression test set.
9. 09Name the person accountable for anything that reaches a supporter.
10. 10Agree how you will judge whether it actually helped—before you roll it out.

None of this requires an unusual level of technical ambition. It requires being specific, and being willing to fix the data underneath.