Build a Donor Support Agent on Agentforce Nonprofit and Data Cloud

Nonprofit teams are small and the questions are repetitive. "Did my gift go through?" "Can you send last year's tax receipt?" "I want to change my monthly amount." A well built agent handles these end to end, at 11pm, without a staff member. A badly built one tells a grieving donor the wrong thing about their late spouse's recurring gift. This is the blueprint we use, including the readiness checks that decide whether you should build it at all.

Why donor support is the right first agent

Agentforce Nonprofit ships purpose-built agents for prospect research, participant management, volunteer coverage, and donor support. Of those, donor support is usually the right place to start, for four reasons:

• The volume is real and repetitive. A handful of question types cover most of the inbox.
• The data is already structured. Gifts, commitments, and designations are records, not judgement calls.
• Success is measurable. Count the emails and calls that no longer reach a human.
• The time saved goes somewhere valuable. A development team freed from receipt requests can do donor relationships, which is the work that actually raises money.

Prospect research agents are more exciting and much harder to evaluate, because nobody can tell you whether the research was good. Start where you can prove the outcome.

Readiness: six checks that must pass first

This is the section to take seriously. An agent reasons over the data you already have. If that data is wrong, the agent produces confident wrong answers in front of donors, which is worse than no agent at all.

1. Duplicate donors are resolved. If Margaret Chen exists three times, the agent will report a third of her giving history. She will conclude you do not know her, which is the opposite of the intended effect. Run duplicate detection and resolve the top matches before you start.
2. Gift data is complete and reconciled. Every gift has a designation, a date, an amount, and a payment method. Your Salesforce totals agree with your accounting system. If they do not agree, the agent will quote a number your finance team disputes.
3. Recurring commitments reflect reality. Every active recurring gift has a corresponding commitment record with the right amount, schedule, and status. Lapsed ones are marked lapsed. This is the most common gap we find.
4. Receipting rules are documented. What counts as tax deductible, how the fair market value of benefits is handled, what the acknowledgement thresholds are. The agent cannot infer your receipting policy, and getting it wrong has consequences beyond embarrassment.
5. Policy content is current and owned. If you plan to ground on documents, somebody must be responsible for whether they are up to date. Indexing an abandoned folder produces an agent that quotes a 2022 policy.
6. Sensitive fields are identified. Wealth screening scores, capacity ratings, solicitation notes, and relationship intelligence. You must know where these live before you design permissions, because the agent must never surface them.

Scoping: what the agent will and will not do

Get the actual question list from real data. Export three months of the donor inbox and a sample of call notes, then categorise. Do not use a list produced in a meeting, because it will over-represent interesting questions and under-represent the boring high-volume ones that make the business case.

A typical distribution looks like this:

Cancellation deserves comment, because it is tempting to automate and you should not. A cancellation request is a retention conversation, and a human can often convert it into a pause or a reduction. Handing that to an agent trades a small efficiency for real lost income.

Write the "never attempt" list down and put it in the instructions. It is the most valuable document in the project.

The running user and permission design

Agent actions execute as the agent running user, subject to that user's object, field, and record access. This makes the running user your hardest guardrail, and the one place where getting it right protects you regardless of what the conversation does.

Create a dedicated user. Never an administrator. Then build a permission set that grants only:

• Read on the donor's own account and contact records, and on gift transactions, gift commitments, and designations.
• Read on the campaigns and funds needed to explain a designation.
• Write on contact points, so it can update an address or email.
• Write on gift commitments, only if you have decided the agent may change a recurring amount.
• Create on cases or tasks, so it can escalate.

Then explicitly withhold field level access to everything in the sensitive category: wealth screening scores, capacity ratings, solicitation strategy notes, relationship intelligence, and any internal commentary about the donor. If the running user cannot read a field, no conversation can extract it. That is the whole point.

If your org has programme participant data as well as donor data, the agent must not reach it. A donor support agent has no legitimate need to see who attended a shelter or a clinic. Our approach to keeping those worlds apart is in the nonprofit sharing model guide.

Grounding: records and documents

You need both routes, because donors ask two different kinds of question.

Structured questions such as "did my gift go through" and "how much did I give last year" ground directly on records. Retrieve the gift transactions for the donor, filtered by date, and let the agent report them. No Data 360 required. Keep the returned field set small: date, amount, designation, payment method, and status is usually enough, and returning 40 fields degrades the answer.

Policy questions such as "is my gift tax deductible" or "where does my money go" need document grounding. Build a hybrid search index over your receipting policy, gift acceptance policy, designation descriptions, and impact reporting content, then create a retriever over it.

Choose hybrid search rather than vector search alone here. Donors use precise terms: fund names, campaign names, appeal codes, and the specific phrase "tax deductible". Keyword matching handles those; semantic matching alone will miss them. The full setup is in RAG with Data Cloud retrievers.

One filter that matters: keep internal content out of this index. Gift acceptance guidance often contains internal decision criteria and escalation thresholds that should not be quoted to a donor. Either filter it or use a separate index.

The eight actions worth building

Build these as Flows unless something specifically needs Apex. Each one gets a description that says what it does, when to use it, and what it does not do, because the planner selects actions by reading those descriptions.

1. Find donor. Resolves a person from an email address or a name and postcode. Returns a single match or an ambiguity indicator. Never guesses between two candidates, because guessing here means discussing one donor's gifts with another.
2. Get recent gifts. Returns gifts for a donor within a date range, with date, amount, designation, and status. Small field set, capped result count.
3. Get annual giving total. Returns the total for a tax year, separating tax deductible from non-deductible amounts. Compute this in the action, not in the model. A language model must never do arithmetic that appears on a receipt.
4. Resend tax receipt. Triggers your existing receipt generation for a specified year and sends it to the address on file. Sends only to the stored address, never to an address supplied in the conversation, which closes an obvious extraction route.
5. Get recurring commitment. Returns the active commitment: amount, frequency, next payment date, designation, and payment method status.
6. Change recurring amount. Updates the amount on an active commitment, within limits enforced in the action. Requires explicit donor confirmation of the new amount before executing, and is idempotent so a retry cannot apply the change twice.
7. Update contact details. Writes a new address, email, or phone to contact points. Requires verification of identity first.
8. Escalate to a human. Creates a case or task with the conversation summary, the donor record, and a reason code. This is the most important action in the list, and the one most often built last.

Notice that two are lookups with no side effect, five are narrowly bounded, and one is an exit. That shape is deliberate. The guidance on building each type is in Agentforce custom actions.

Escalation rules for a donor-facing agent

Nonprofit donor conversations carry emotional weight that commercial support conversations do not. These triggers should hand off immediately, with a warm message and no attempt to resolve:

• Any mention of death or bereavement. A donor writing about a late spouse's gift, or asking to stop a deceased relative's donations. Get a human involved within the hour. Nothing an agent says here improves the situation.
• Cancellation requests. A retention conversation, as above.
• Complaints, about your programmes, your spending, your leadership, or your communications. An agent responding to a complaint reads as institutional indifference.
• Bequests, legacies, and planned giving. High value, legally sensitive, relationship driven.
• Anything about a specific beneficiary. Donors sometimes ask about the person their gift helped. That data must never be disclosed, and the request needs a careful human answer about why.
• Distress of any kind, including financial hardship affecting their ability to give.
• Media or research enquiries arriving through the donor channel.
• Three failed attempts at anything. Escalate rather than looping. A loop is how a mildly annoyed donor becomes an angry one.

Make escalation a success, not a failure, in how you frame and measure it. An agent that cannot escalate gracefully will improvise, and improvising with donors is the risk you are trying to eliminate.

Writing the subagent instructions

Instructions are policy statements, not personality descriptions. Concretely, cover:

• Identity verification. State exactly what must be confirmed before discussing any gift detail. Do not rely on the profile alone to establish who is speaking.
• One donor per conversation. Never discuss another person's giving, including a spouse's, without separate verification. Household records make this easy to get wrong.
• Prohibited topics, stated explicitly. Tax advice, valuation of non-cash gifts, beneficiary information, other donors' gifts, and internal assessments of the donor.
• Tone. Warm, brief, grateful, plain. Donors are not customers and generic service language reads badly to them.
• Uncertainty behaviour. Say plainly that you will have a colleague follow up rather than guessing. Then escalate.
• Mandatory escalation triggers, the list above, stated as absolutes.

Remember the limit of this layer. Instructions are strong suggestions to a probabilistic system. Anything that must never happen belongs in the permission set or in code. Withholding field access is enforcement; asking nicely is not.

Testing before a donor ever sees it

Use Agentforce Testing Center with a set built from real donor messages. Include, deliberately:

• The top five questions, each phrased four or five different ways, including badly punctuated and very short versions.
• A bereavement message. Confirm it escalates and does not attempt a resolution.
• A complaint. Confirm the same.
• An attempt to get another person's giving history, phrased innocently: "can you tell me what my husband gave as well".
• A request for a receipt to be sent to a different email address.
• A donor who cannot be identified from what they provide.
• A donor matching two records, to confirm the agent asks rather than picks.
• A question your content genuinely cannot answer, to confirm it says so.
• A request for tax advice.

Re-run the whole set after every change, including changes that look unrelated. Adding an action changes routing for the existing ones, because the planner now has another option to weigh.

Then pilot narrowly. One channel, or a limited donor segment, with a staff member reading every transcript for the first two weeks. You will find two or three things no test set predicted. That is the expected outcome of a pilot, not a sign it went badly.

Measuring whether it worked

Record the baseline before launch or you will never be able to prove improvement. Specifically:

• Donor enquiry volume reaching a human, by category. This is your primary number.
• Median time to first response, before and after.
• Full resolution rate, meaning conversations closed without human involvement. This is the number that justifies the cost.
• Escalation rate by trigger, which tells you whether the boundaries are set correctly.
• Retention of recurring donors, watched carefully. If it moves down, investigate immediately.
• The questions it could not handle, which is your roadmap for the next iteration.

A realistic target for a well built donor support agent is full resolution of the top three question types and useful triage of the rest. If the agent hands nearly everything to a human, it is an expensive router and you should reduce its scope until it does a smaller thing completely.

What it costs to run

Two cost lines, and the second is usually the larger.

Consumption. Agent conversations are metered, and Data 360 usage is metered in credits, so cost scales with volume. Model the expected conversation count against your enquiry baseline before committing. Get current rates from your account executive and ask what nonprofit pricing applies.

Readiness and upkeep. The duplicate resolution, gift reconciliation, and policy documentation from the readiness section are real work, and somebody has to keep the grounding content current afterwards. Budget an owner, not just a build.

On budgeting more broadly, including what the Power of Us Program does and does not cover, see what Salesforce really costs a nonprofit.

Frequently asked questions