Guides
Publish a donor portal page#
Donors don't create an account or log in. A link mailed or emailed to them is the access grant — the token in the URL is the only credential.
This guide covers the admin side. For a walkthrough of what a donor sees and every self-service action they can take, with screenshots, see The donor portal.
Why token-based, not login-based#
Requiring donors to create a portal login is friction most never clear — a login they'll
create once and forget. The donor portal instead uses a signed, single-purpose link
(/donor?t=…); anyone with the link can view that specific donor's dashboard, and no one
without it can. This is a deliberate trade-off: possession of the link is the
authentication. Links are generated and delivered by Salesforce in a dedicated magic-link
email, sent only when a donor explicitly requests access (see step 2) — never typed in or
guessable, and the token is not a record Id and record Ids are never used to address these
pages directly.
Before you start#
Confirm you have an Experience Cloud site provisioned, including a Donor Dashboard page at the
donor URL (Professional edition orgs and orgs without a site can't publish this) — see
Set up your Experience Cloud site if you
haven't built it yet. The Fundraising_GuestDonor permission set must be assigned to the
site's guest user profile.
1. Enable the portal#
Settings → Experience Cloud → Donor Portal. Turn on the panels you want donors to see —
giving summary, recurring gift management, giving history, saved payment methods. Each is an
independent "Show panel" toggle — turn it on to show that panel to donors, off to hide it.
(Under the hood these are stored as inverted Donor_Portal_Hide_*__c fields, but the panel
presents them as normal, positive-framed toggles.)
**What it shows.** The Donor Portal panel's Panels section — toggles for the giving summary, recurring gifts, donation history, and saved cards sections, each with helper text — and the start of the Request-Link Screen copy fields below.
2. Customize the request-link and confirmation screens#
The same panel controls the copy shown on the "request a link" screen (where a donor who didn't keep their original link can ask for a new one by email) and the confirmation screen shown after a link is requested. Both default to reasonable generic copy; personalize them with your org's name and tone.
3. Set empty-state messaging#
If a donor has no recurring gifts or no giving history yet, the portal shows an empty-state message rather than a blank panel — customize this too, so a first-time donor doesn't land on something that reads like an error.
4. Publish the Experience Cloud site#
Publishing the underlying Experience Cloud site is a separate step from the Settings toggles above — Setup → Digital Experiences → your site → Publish. Settings changes take effect immediately for anyone with a valid link; site-level changes (a new LWC version, for example) require a publish to go live for guest users.
Publish, then hard-reload before verifying
A deploy alone is not enough for guest-visible changes to take effect — the Experience Cloud site must be explicitly published. After publishing, hard-reload the page before checking your work; a cached bundle can otherwise make a successful publish look like it didn't take.
What donors can do#
| Panel | Capability |
|---|---|
| Giving summary | Their own name and email, the month they first gave, lifetime total, this-year total, and lifetime gift count |
| Where it went | A breakdown of their own giving by fund, net of refunds — the four largest funds by name, everything else rolled into "Other funds". Shown only once a donor has given to more than one fund, and only where gifts were split across funds at all |
| Recurring gifts | View active recurring gifts; change the amount; change which fund the gift supports (limited to the funds the campaign offers); skip the next payment; pause or resume; retry a failed charge immediately or reinstate a lapsed gift; switch the saved card a gift charges, or add a new card (via a Stripe SetupIntent); cancel |
| Saved cards | View the cards already on file, and remove one they no longer want offered. Removal is refused while a live recurring gift still charges that card — active, paused, or one whose last payment failed — so the donor moves the gift to another card first. A removed card is hidden, not deleted, so refunds on gifts already paid with it stay traceable; giving with it again puts it back |
| Giving history | View and download receipts for past gifts, grouped by year with a per-year gift count and total |
| Annual giving statement | Pick a tax year and print a single statement covering every receiptable gift in it — the year-end document donors otherwise phone in for. Each year offered shows its gift count and total before the donor commits to a download |
| Event tickets | View and print tickets for events they've registered for (/tickets?token=…) |
The fund breakdown nets out refunds, and a refund follows the split
A refunded gift does not simply vanish from the breakdown — the refund is apportioned across that gift's funds in the same proportion the original gift was, so a $400 gift split 3:1 between two funds and later refunded $200 reduces those funds by $150 and $50. The percentages a donor sees are rounded once, on the server, so the chart and its legend can never disagree.
The statement is on demand, not a year-end mailing
Nothing is sent in January. A donor produces their own statement whenever they want one, and staff can produce the same document from a Contact or Account record page when a donor asks over the phone. The two paths render through the same code, so a donor who prints their own statement and one your team emails them are the same document — which matters if the two ever end up side by side in front of a tax authority. Only years the donor actually gave in are offered, so an empty statement is never produced.
Related#
-
The donor portal
What donors see and can change, screen by screen.
-
Recurring giving
What donors are changing when they switch a saved card.
-
Donors & accounts
How a donor's identity resolves regardless of account model.
-
Settings & integrations
Where donor-portal configuration sits in the settings model.