Skip to content

Getting Started

Settings console reference#

A field-by-field reference for the Settings console: what each setting does, and — the part that actually matters day to day — what happens the moment you save it.

This page is the companion to Setup assistant, which tours the console's four groups and fourteen panels. This page goes one level deeper: every field, in every panel, with two questions answered for each — what it does, and behavior on update (does the change apply immediately, only to new records going forward, only on the next scheduled batch run, or not at all).

How to read "Behavior on update"

  • Immediate — the very next Apex transaction/page load sees the new value. Settings__c is a Hierarchy Custom Setting; saving it commits instantly with no platform-cache delay.
  • Immediate, but browser-cached — the server-side value changes instantly, but the specific screen that displays it uses a cacheable (@AuraEnabled(cacheable=true)) wire, so an already-open browser tab may keep showing the old value until it reloads or its cache is invalidated.
  • New records only — the setting is a default copied onto a record at creation time. Existing Campaigns, designs, or donations are never touched retroactively.
  • Next scheduled run — a nightly/hourly batch reads the setting; nothing changes until that job next executes (or an admin manually triggers it from System → Scheduled Jobs).
  • No effect (known gap) — the field is editable and saves cleanly, but no code anywhere reads it. Flagged explicitly below rather than silently omitted, so you don't waste time troubleshooting a toggle that was never wired to anything.

General#

Organization & Donations (General → Organization & Donations)#

Setting What it does Behavior on update
Org display name Org name shown on receipts and portal emails Immediate
Tax ID (EIN) Tax ID printed on receipts Immediate
Default currency Default currency code applied to new gifts/campaigns New records only — existing campaigns keep their own currency
Campaign type for new fundraisers The Campaign Type stamped on fundraisers you create from now on — the field standard Salesforce campaign reports and dashboards group by New fundraisers only; an existing campaign's type is never rewritten by an edit. The dropdown lists your org's Campaign Type picklist, so add a "Fundraising" value in Setup first if you want one. Leave it on "Use the org's own default" to keep whatever default your org already set — but be aware Salesforce's own stock default is Conference, which is why fresh installs are seeded to Other
Default suggested amounts Suggested-amount chips (comma-separated) pre-filled on a brand-new fundraiser New records only — pre-fills the "New fundraiser" wizard; editing this later never changes an already-created fundraiser's amounts
Default fee-on-top percent (No effect — known gap.) Nothing reads this value; "cover the fee" behavior, where implemented, is controlled per-campaign, not by this org default.
Donation page path Path fragment appended to your Experience site's base URL to build public donation links Immediate for the embed widget's REST endpoint and the Fundraisers console's public-links panel; immediate but browser-cached for the Campaign Gallery (its donation links come from a cacheable wire, so an already-open gallery tab may show the old path until it reloads)
Donor options — Allow tribute/honoree gifts Org-wide master switch for tribute/honoree gifts — and the starting value for a brand-new fundraiser's own toggle Immediate and org-wide. Off = no fundraiser shows the tribute section, no tribute data is captured, and no honoree e-cards go out, whatever an individual fundraiser's toggle says. On = each fundraiser's own toggle decides. Per-fundraiser choices are never overwritten, so they come back exactly as they were if you switch this off and on again
Donor options — Allow company-match prompt Default for whether a brand-new fundraiser shows a company-match prompt Same pattern as tribute gifts above
Donor options — Add donors as Campaign Members Adds each donor to the Campaign their gift came in on, so Contacts in Campaign / Responses in Campaign and the standard campaign reports stop reading zero Off by default, and off is a working state — the app's own Fundraising Progress card and rollups are correct either way. On applies to gifts finalized from now on; it never back-fills past donations. Leave it off if your org already adds campaign members with its own automation. Event attendees have their own separate switch under Events. See Campaigns
Donor options — Assign soft credit automatically Credits a gift given in honor of someone to that person, and credits a donor's household alongside them On by default. Never changes who paid or how much — it only adds credit rows so both parties appear in giving history without the gift being double-counted
Min / Max donation amount Floor/ceiling enforced on gift amounts Immediate — enforced server-side before any Stripe callout; also passed to the donation form as a client-side hint
Donor portal link validity (hours) How long a donor's magic-link sign-in stays valid. Defaults to 3 hours; the request screen and the email both quote whatever you set here, so the donor is never told a window you haven't configured Immediate for newly-issued links; does not shorten/lengthen a link already sent to a donor
Default thank-you CTA URL / label Fallback call-to-action button shown after a gift, when a campaign doesn't set its own Immediate — a campaign's own thank-you fields, where set, take precedence over this org default
NPSP: sync recurring donations / sync GAU allocations Whether recurring gifts / GAU splits sync into NPSP objects Next donation-finalize event only — never retroactively syncs past donations. Only shown once NPSP is detected in your org.
Person Accounts / NPSP detected (read-only) Informational display of what the "Detect capabilities" scan found Informational only — actual donor-resolution logic re-checks your org's schema live at donation time regardless of what this panel shows
Detect capabilities button Re-runs the org-schema scan for Person Accounts / NPSP Immediate, but manual — installing NPSP or enabling Person Accounts won't update this panel until you click it
Logo upload Org logo shown on receipts, emails and the public donation page header Immediate
Public page footer — footer text The copyright/attribution line in the footer band of every public donation page Immediate and live on the next page load. A campaign can override it on its own record; leave a campaign's override blank to use this.
Public page footer — terms / privacy URLs The two policy links in that footer band Immediate and live. Leave one blank and the footer simply omits that link rather than rendering a dead one. Same per-campaign override.
Public page footer — X (Twitter) / Facebook / Instagram URLs The social icons in that footer band Immediate and live. Each is independent — an unset network shows no icon. Same per-campaign override.
Social share image URL The 1200x630 card a social network shows when someone pastes a campaign link Saved and resolved, but not yet rendered into an og:image tag by anything in this package — it is stored ready for a social-preview feature. Blank falls back to the packaged card published at install.
Story media — Play story videos on the page Whether a video block in a campaign story plays inline, or stays a click-out poster card. Off by default, and off is a working state — the card loads nothing from YouTube until a donor clicks it Immediate and live on the next page load. On is only half the job: inline playback also needs a CSP Trusted Site for https://www.youtube-nocookie.com (frame-src, context Experience Builder Sites) that you create yourself in Setup — the package ships none, deliberately, so the install-time third-party access dialog stays payment-processor-only. With the toggle on and no trusted site the browser blocks the frame silently; no Salesforce API can tell the app whether you created it, so the panel states the requirement rather than grading it. See Write a campaign story
Reset to defaults button Resets settings to their packaged defaults Immediate, but narrower than the label suggests — it resets exactly 10 fields (retry/grace/dunning intervals, suggested amounts, default currency, auto-receipt toggle, debug logging, and the two donor-option toggles). It does not touch org name, Tax ID, email colors/copy, min/max amounts, portal link validity, thank-you CTA, or NPSP sync toggles.

Anonymous giving has been removed

Earlier releases carried an "Allow anonymous giving" toggle here and an Anonymous__c checkbox on donations and recurring donations. Nothing ever wrote them — no donation form asked donors the question — so they have been removed rather than left as settings that appear to work. Anonymous giving may return as a real, end-to-end feature in a later release.

Email & Receipts (General → Email & Receipts)#

Setting What it does Behavior on update
From name The sender display name on donor email — but only while From email below is empty. Once a From address resolves to an Org-Wide Email Address, Salesforce takes the display name from that record and this field stops being applied (the two are mutually exclusive in the platform API) Immediate, for the next email sent
From email Two independent jobs. (1) It is the lookup key for the address donor email is sent from: the package matches it against your org's Org-Wide Email Addresses and, if it finds one that is both verified and has Allow All Profiles to Use this From Address ticked, stamps every donor message with it. (2) It is printed as your contact address on seven emails — failed payment, re-authorization, dunning, refund confirmation, employer-match instructions, and the two tribute notices Immediate. A value that matches no such Org-Wide Email Address fails silently at send time: the email still goes out, just from whichever user or background job triggered it. Both boxes matter — receipts are sent by the site's guest user and by scheduled jobs, which is why Allow All Profiles is not optional. Run Health Check → the Donor Email Sender line to see which half is missing
Reply-to email Sets the Reply-To header on every transactional email the package sends. It doubles as the fallback staff recipient — a refund request or card-dispute alert with no gift owner to notify is sent here Immediate. Blank means replies go to the sending address itself
Support phone Shown on Dunning, Failed-Payment, and Re-Auth emails Immediate where shown. Not shown on the donation receipt or recurring-confirmation emails — a donor never sees it unless something goes wrong with a payment.
Brand colors (primary / accent / heading / background) Hex colors used on the receipt email Immediate. Server-side validated as a 6-digit hex (#rrggbb) — an invalid value is rejected with an error, not silently accepted.
Auto-send receipt Whether a receipt email fires automatically when a donation finalizes Immediate, for the next finalized donation
Receipt email template Which classic Email Template to render for receipts Immediate — but if the name you enter doesn't resolve to a real template, it silently falls back to the packaged default rather than erroring. A typo won't break receipts; it'll just quietly ignore your custom template.
Receipt intro message / signature / footer text Copy blocks on the receipt email Immediate
Receipt legal text — no goods received The legal sentence at the foot of a receipt for a plain gift, where the donor received nothing in return. Applies to every receipt surface, not just the email — the donor-portal receipt, the printed receipt, and the annual giving statement use it too Immediate. When set it is used verbatim for this case and the packaged wording is suppressed. Leave blank for the packaged US 501(c)(3) default. It is never used for an event order — that has its own field.
Receipt legal text — goods received The sentence used instead when the donor got something back (an event or ticket order), including one whose tier carried no fair market value Immediate, same surfaces. Must not say "no goods or services were provided" — that is false for these gifts and regulated in the US. Leave blank for the packaged default.
Receipt legal text — goods received, partly refunded The sentence for the rare receipt covering a partly refunded event order, where no deductible figure can be stated Immediate, same surfaces. Should tell the donor to contact you for the deductible amount. Leave blank for the packaged default.
Receipt number prefix The leading segment of every receipt number — RCPT produces RCPT-2026-000142. Blank uses RCPT. Immediate, for the next receipt issued. Letters, digits and underscores only; anything else (including hyphens, which are the separator) is dropped, and the value is upper-cased when the number is built. Changing it never renumbers receipts already issued — the two formats simply coexist, which is fine because the numbers only have to be unique, not uniform.
Recurring thank-you message Copy on the recurring-donation confirmation email Immediate
Org mailing address Compliance address printed on receipts Immediate
Donor portal path Path fragment for the donor-portal link included in dunning emails Immediate, but inconsistently normalized: most consumers of this value auto-fix a missing leading slash, but the Dunning email template concatenates it raw. If you omit the leading slash here, the link in dunning emails specifically can come out malformed even though everywhere else treats it the same either way. Enter it with a leading slash (e.g. /donor) to avoid the discrepancy.

Events & Ticketing (General → Events & Ticketing)#

Setting What it does Behavior on update
Deductible calculation mode Whether the non-deductible portion of a ticket price is computed from each ticket type's Fair Market Value, or as a flat percentage. The two fields are not interchangeable — each mode reads only its own, and ignores the other New tickets only — only affects orders finalized after the change; already-issued receipts keep the split that was computed at the time. Switching to Percentage makes the ticket type's Deductible % required from then on; ticket types created earlier keep what they had, and any still missing a percentage records its sales as 0% deductible (whole price non-deductible) and logs a warning, rather than reading a fair-market value a percentage org never fills. Set the percentage on each existing tier — 0 is a valid answer — before selling under the new mode.
Sync attendees as Campaign Members Whether finalizing a ticket order also creates a Campaign Member for each attendee who resolved to a Contact New tickets only. Guest attendees captured as name/email only (no Contact match) are skipped — Campaign Member requires a person record. A sync failure never blocks or reverses the underlying paid order.

Logging (General → Logging)#

Setting What it does Behavior on update
Log level Minimum severity the package's internal logger persists to a queryable log record (Off / Error / Warn / Info / Debug) Immediate — takes effect on the very next log call anywhere in the org, not just from this console
Debug echo to Apex debug log Also mirrors log calls into System.debug for live viewing in Developer Console Immediate. Does not change what's persisted as a queryable log record — that's Log level's job exclusively. Turning this on will not make more log history appear on the Diagnostic Logs tab.
Purge after (days) Age threshold at which the nightly retention job permanently deletes old log records, transaction logs, and completed donation-staging bookkeeping rows Next scheduled run only (nightly, 3am) — changing this has zero immediate effect. Deleted rows are not restorable by raising the value back up afterward.

This panel sets the level — the Diagnostic Logs tab is where you read the result

The entries these settings produce are on their own tab in the app navigation, filterable by severity, context and date and searchable across messages and stack traces. It reads both settings back: if Log level is Off the tab says so outright, and it names the purge window, so an empty list can never be misread as "nothing went wrong" when the real answer is "nothing was written" or "it was already deleted." See Monitor donations and read the logs.

Purge after (days) feeds a real delete, on demand

The nightly purge is scheduled, but an admin can also trigger it immediately from System → Scheduled Jobs ("Retention purge → Run now"). That action deletes using whatever value is saved here at the moment you click it — lowering this number and then running the purge manually will remove more history at once than the nightly job typically would.

Payments#

Payment Accounts (Payments → Payment Accounts)#

Backed by Payment_Account__c records, not Settings__c — this panel is full CRUD on the payment-gateway connections your campaigns charge through.

Field / action What it does Behavior on update
Display label, Payment processor Required fields identifying the account Immediate. The processor list is built from what the package actually implements — Stripe today. There are no reserved "coming soon" options to pick and then be blocked on.
Public named credential The credential donor-facing charges authenticate with — a restricted, charge-only key, and the one your site guest user is granted Immediate. There is no secret-key field anywhere in this panel: you build the External Credential and Named Credential yourself in Setup, and the record stores only the credential's name. The guided checklist above the account list walks that build and then reads your org back to grade it.
Admin named credential The credential back-office work authenticates with — the full key used by refunds, the reconcilers, the orphan sweep, off-session recurring renewals and Test connection Immediate. Never grant this one to a site guest user; step 9 of the checklist names the permission sets your guest holds and asks you to confirm this isn't among them, and step 7's probe reports a failure outright if the guest-reachable key turns out to be a full one. Naming the same credential in both fields is accepted and warns rather than blocks — the checklist then grades the affected steps amber.
Publishable key Stripe's non-secret publishable key, exposed to the donor's browser Immediate. It also determines the Mode badge: a pk_test_… key marks the account Test, pk_live_… marks it Live. There is no mode field to set — and therefore none to set wrongly.
Active Whether the account can be charged through Immediate and load-bearing: deactivating an account instantly blocks any campaign linked to it from taking a charge — the next donation attempt is rejected until an active account is linked.
Delete button Removes a payment account Blocked with an error if any campaign — live or draft — still links to the account. Unlink it from every campaign first.
Test connection button Verifies the account can reach the gateway on its admin credential Runs a real, live connectivity check against the gateway every time you click it — not cached or simulated. It says nothing about the public credential; step 7's Run the check button is what settles that one.

Refunds (Payments → Refunds)#

Setting What it does Behavior on update
Enable refunds Master switch for the entire refund subsystem Immediate for new refund attempts, and for the hourly reconciliation job's next run. Immediate but browser-cached on the record-page refund button itself — an already-open donation record may show the old enabled/disabled state until refreshed.
Refund window (days) How many days past a gift's close date it can still be refunded from Salesforce Immediate for the next refund attempt / reconciliation run

Turning off refunds also stops dispute/chargeback syncing

"Enable refunds" isn't just the refund button's on/off switch — the same flag gates the hourly reconciler that pulls both refund status and dispute/chargeback updates from Stripe. Disabling it silently stops chargeback-lifecycle updates from reaching Salesforce too, not only new refund attempts — a materially larger blast radius than the label implies.

A refund window of 0 quietly disables refunds without touching the switch

Setting the refund window to 0 days makes essentially every already-closed gift fall outside its refund window immediately, functionally freezing refunds org-wide — a subtle way to disable refunds without ever touching "Enable refunds."

Recurring & Dunning (Payments → Recurring & Dunning)#

All four fields here are read once a day by the nightly recurring-billing batch chain (donor rollups → renewal charges → auto-cancel) — none of them take effect immediately.

Setting What it does Behavior on update
Failed payment retries How many times a declined recurring charge is retried before being marked Failed Next scheduled run (nightly)
Retry interval (days) Spacing between consecutive retry attempts Next scheduled run (nightly)
Grace period (days) How long a Failed recurring schedule is kept before being auto-canceled Next scheduled run (nightly) — specifically, the following night's sweep, since auto-cancel runs last in the nightly chain
Dunning email frequency (days) How often a decline/dunning email is re-sent to a donor with a failing payment method Next scheduled run (nightly)

Experience Cloud#

Site & Domain (Experience Cloud → Site & Domain)#

Not a settings form — an eight-step guided checklist (enable → site → guestAccess → permSet → campaignAccess → stripeCred → pages → publish) with a running progress tally at the top. Every step carries exactly one status chip: Done (confirmed against your org this load), Pending (confirmed not done — the action is yours), or Can't verify (Salesforce exposes no API to check that step, so the panel says so rather than guessing at guest access or your page list — two things that remain permanently unreadable from Apex, not broken).

Steps 5 and 6 grant what the package cannot ship — and both are machine-checked

A managed package may grant neither a standard object permission (step 5, the guest user's Read on Campaign) nor an external-credential principal (step 6, the public Stripe credential). Salesforce strips the first out of a packaged permission set when the version is built and rejects the second outright, so Fundraising_GuestDonor carries every custom-object and custom-field grant your public pages need and neither of these two. Both are therefore one-time admin grants — and both are read back here, so you see Done or Pending rather than being asked to confirm your own work. Step 5 counts the grant wherever it lives: on the guest user's profile (the usual place) or on a permission set of your own assigned to it.

Step 6 (Stripe credential grant) is machine-checked, not self-confirmed

This step shipped permanently Can't verify on the assumption that an external-credential principal grant is unreadable from Apex — that assumption was wrong. ConnectApi.NamedCredentials .getExternalCredential() exposes the credential's principals, SetupEntityAccess names the permission sets that grant one, and the site's guest user's own permission-set assignments are a plain query — so the panel now reports Done (a permission set granting the credential is assigned to this site's guest user) or Pending (it isn't), the same as every other checked step. The package still can never ship this grant — a managed permission set may not grant an external-credential principal — so the admin still builds it by hand once; the panel just no longer has to ask you to confirm your own work.

Step / action What it does Behavior on update
Site picker + Use this site Connects the console to one of your org's Experience Cloud sites Immediate — every other panel/endpoint that resolves "the" site reads the same stored value, so they can never disagree
Step 7 page table Lists all six public pages (Home, Donate, Thank you, Receipt, Donor portal, Tickets) against the path your org is actually configured with, plus a live link to open each one Read-only — pages are still built by hand in Experience Builder; this table never writes anything

Embedding (Allow embedding master switch + Allowed embed origins) sits as its own always-open block at the foot of the panel, deliberately outside the eight-step checklist and its tally — it's optional and unrelated to whether the site itself is ready to take donations. Allowed embed origins is not validated — an entry missing https:// or containing a path will simply never match a real request origin, with no error surfaced anywhere; double-check each entry is a bare scheme+host.

Full walkthrough: Set up your Experience Cloud site.

Entirely read-only — nothing on this panel is a setting you change here. It's a live, always-fresh readout of donation/fundraiser/team links built from the Donation page path (set in Organization & Donations) and the site connected in Site & Domain.

Looking for the donation page path?

It isn't edited here — it lives on General → Organization & Donations, under Gift rules.

The Campaign Gallery can lag behind this panel

This panel always shows the current path/links. The public-facing Campaign Gallery page, however, loads its donation links through a browser-cached call — a visitor with the gallery already open may keep seeing the old donation path until their browser reloads it. The embed widget and internal admin links are not cached and reflect changes immediately.

Page Designs (Experience Cloud → Page Designs)#

Backed by Campaign_Design__c records — themes and layout composed in the Page Canvas builder, applied to campaigns by reference.

Your logo, footer and social links are no longer part of a design

Each design record used to carry its own logo URL, footer text, terms/privacy links and social handles. Those describe your organization, not a theme, so a campaign switching from one style to another silently changed which privacy policy its donors were pointed at. They now live once, in General → Organization & Donations, and every design renders the same set. A campaign that genuinely needs its own — a joint appeal, say — overrides them on its own record.

Setting / action What it does Behavior on update
Active toggle Whether the design can be used Immediate and live for every campaign already using it — not just new ones. Turning a design's Active flag off instantly falls back any campaign pointing at it to your default design, the next time a guest loads that campaign's page.
Set as default Which design campaigns with no design chosen fall back to — and the theme every public page that is not a donation page paints itself from (the campaign gallery, the donor portal, the thank-you page, receipts and the ticket wallet) Immediate and live — same instant-fallback behavior as above. Exactly one design can hold the flag: marking a design default clears it from whichever design held it before, wherever the change was made — this console, the Salesforce record page, a data load or an import.
Colors, fonts, hero image, spacing/shadow/radius style Visual theme tokens Immediate and live for every campaign on that design, on their next page load — no Experience Cloud site republish needed, since this is a data change, not a component/metadata change
Column ratio How the public page splits between the story column and the payment box, and which side the payment box sits on — 60/40, 50/50 or 40/60 Immediate and live. A campaign can override it on its own record.
Form title/description/disclaimer/footer defaults Default form copy for campaigns using this design Immediate and live, but a campaign's own override (where set) always wins over the design's default
Show progress bar Whether the raised-of-goal progress bar renders — on the hero banner, the donation form and the embedded widget alike Immediate and live. Switching it off removes the bar from all three surfaces. It has nothing to remove on a campaign with no goal amount, or on a Ticketed Event campaign (which shows a tier picker instead), so on those it is a no-op by design, not a bug.
Show donor wall (No effect — known gap.) Saved and passed through to the guest page's data, but no guest-facing component currently reads this flag to gate anything.
Theme tokens (advanced JSON) Raw override of the design's theme-token values Immediate. Any token name not on the packaged, protected allow-list is silently dropped when the design is read back — it is not rejected at save time, so a typo in a token name won't error, it'll just be ignored.

The advanced token list grew a lot

The Add override dropdown on a design's Advanced tab now carries 147 tokens, grouped by what they affect. Five of those groups — Story, Sections, Tabs, Donation box and Footer — cover the two-column public page: the hero crop and its overlay, the story column's line length and paragraph rhythm, the documents/updates/FAQ tab strip, every surface of the donation box down to the progress bar, and the contact band at the foot of the page. Anything you can see on a public donation page that isn't the campaign's own content is a token you can change here, which is what lets two designs look like two different products rather than two colour schemes of the same one.

One design is default, and it dresses more than the fallback

Only a donation page follows its own campaign's design. Every other public page — the campaign gallery, the donor portal, the thank-you page, receipts and the ticket wallet — has no campaign to read, so it paints itself from whichever design is marked default. Changing the default therefore restyles all of them at once: colours, fonts, corner radius and spacing. That includes the donor portal's buttons and its statement and trust panels, which take the default design's primary colour rather than a fixed one.

Warnings follow the theme; errors deliberately do not

Each packaged design also sets its own caution colours — the amber used for a pending refund line, a "few tickets left" chip, or an expiring card notice — so a warning sits in the same temperature as the rest of the page. Marigold is the exception and warns in terracotta, because its own brand colour is already ochre and an amber warning would read as a second heading rather than as a warning.

Error colours are the same on all six designs (#C7362B with its tint and hairline) and intentionally so. An error is a safety signal: a failed card, a closed campaign, a form that won't submit. If it took each design's own palette it could end up looking like the brand — the donate button and the "your payment failed" box in the same red. You can still override the error tokens on a design's Advanced tab, but think twice before pointing them at your primary colour.

The hero is sized by proportion, not by height

A design sets Hero aspect ratio (--pf-hero-ratio, e.g. 21 / 8) rather than a pixel height. A fixed height crops the same photo to a different slice of itself on a phone than on a desktop; a ratio keeps the crop identical at every width. The old --pf-hero-header-height token was retired — a design that still lists it in its advanced JSON will have that entry dropped on the next read, with no error.

| Page Canvas blocks | The Compose → Payment → Thank You block layout | Immediate and live | | Delete button | Removes a design | Blocked with an error if any campaign currently references it — you must reassign or clear those campaigns' design first. (The confirmation dialog's own wording implies a silent fallback to the default design instead; the actual behavior is a hard block, not a fallback — don't rely on the dialog text.) |

Delete is blocked, not a silent reassignment

The delete-confirmation dialog reads as if campaigns using the design will simply fall back to your default. In practice, the delete is refused outright while any campaign still references it — reassign or clear those campaigns' design field first.

Donor Portal (Experience Cloud → Donor Portal)#

All fields below feed the donor-facing self-service portal and take effect immediately server-side; because the portal's own configuration read is a cacheable wire, a donor who already has the portal open may not see a just-changed title, message, or visibility toggle without a page refresh.

Setting What it does Behavior on update
Show summary / recurring / history / wallet panels Which sections of the portal are visible to a donor Immediate, browser-cached (see above)
Request title / subtitle Copy on the portal's magic-link request screen Immediate, browser-cached
Confirmation title / message Copy shown after a donor requests a magic link Immediate, browser-cached
Empty recurring / history / wallet messages Copy shown when a section has nothing to display Immediate, browser-cached

Keep the confirmation message generic

The same confirmation message is shown whether or not the entered email actually matched a donor — this is a deliberate anti-enumeration measure. Nothing in the code enforces this; if you customize the message, keep it generic yourself, or you risk leaking whether an email address is a donor in your system.

System#

Record Types (System → Record Types)#

This panel is not read-only. Each row can be overridden to point package logic at a different Record Type than the packaged default.

Action What it does Behavior on update
Edit → choose a record type → Save Overrides which Record Type the package stamps on new records for that object New records only — every record this app creates for that object going forward uses your chosen Record Type. Records already created are never modified.
Reset / "Reset to default" Clears an override, reverting to the packaged Record Type New records only, same as above

Health Check (System → Health Check)#

Check What it does Behavior of its "Fix" button (where shown)
Scheduled Jobs Counts the cron entries the package expects — the donation finalizer, the reconciliation heartbeat, recurring billing, retention purge, refund/dispute reconciliation, the Stripe payment sweep, and the nightly campaign-total rebuild. It confirms they are scheduled, which is not the same as running; Gifts Being Recorded below is the row that knows the difference. Once a payment account exists it also answers a second question in the same sentence: can the jobs that call the gateway authenticate? A named-principal callout runs as the job's owner, so it goes red and names that owner when they hold no permission set granting an external credential principal — the state in which every refund, renewal and sweep fails silently while the count stays green. A package cannot see which credential a grant belongs to, so when every owner is granted the row keeps its colour and asks you to confirm the grant is on the credential your payment account names Fix schedules whatever is missing and re-owns any job whose owner no longer resolves. Safe to click at any time — a job that exists and is running is left alone, cadence included. It also appears for a stranded owner, but only if you yourself hold a credential grant — the repair is to reschedule the jobs under your login, which helps nobody if your login cannot authenticate either. If it isn't shown, grant the principal first (see Grant the credential)
Gifts Being Recorded Confirms the finalizer is actually running, not merely scheduled. The Scheduled Jobs row above counts jobs; this row reads a marker the finalizer stamps from inside itself, so it catches the case where all jobs are present but every run is failing. Three states, not two: green when a pass completed recently, amber when no pass has ever completed and no gift is waiting on one — every fresh install, where the work is real but nothing is at risk — and red when gifts are genuinely charged with no donation record, naming the count Fix re-schedules the whole pipeline under your own login, including re-owning any job the install left with an unreachable owner — the same repair as the Scheduled Jobs row. Available on amber as well as red, because the fresh install is the state that most needs it. Re-run the check a few minutes later
Donor Email Sender Confirms the From email on Email & Receipts actually resolves to an Org-Wide Email Address the package can send as — one that is verified and has Allow All Profiles to Use this From Address ticked. This is the only place the difference surfaces: a From address that resolves to nothing costs no donor a receipt, it just sends every one of them from whichever user or background job happened to trigger it No Fix button — the record has to be created and verified in Setup → Organization-Wide Addresses. The row names which of the two boxes is missing
Record Type Mappings Confirms all expected Record Type slots are mapped Fix adds only the missing default slots — it never overwrites an override you've already set
Payment Accounts Confirms at least one active payment account exists No Fix button — go configure one on the Payments panel
SOQL Limit (this request) Reports this request's own SOQL query usage Informational only — a per-transaction number, not an ongoing org-wide usage metric
Experience Cloud Site Confirms a site is connected (Known UI gap.) Its Fix button shows a success message but does not actually create anything — it only returns the same CLI command shown on the Site & Domain panel. The check will still show as failing after you click Fix; you still need to run that command yourself.

"Fix" on the Experience Cloud Site row doesn't fix it

Clicking Fix shows a "Fixed" toast, but no site is created — it's informational only, same as the "Copy CLI command" action on Site & Domain. Run the CLI command yourself, then reconnect from the Site & Domain panel.

Scheduled Jobs (System → Scheduled Jobs)#

Controls the package's background cron schedule directly — not Settings__c fields.

Every scheduled job appears as a card showing what it does, when it runs, and whether it is waiting or paused. The two families — Donation Finalizer and Reconciliation Heartbeat — expand to a cadence editor, because they need to run more often than once an hour and Salesforce can only express that as several jobs spaced across the hour (which is why one family shows a dozen rows; they are not duplicates). Every other job runs on a fixed schedule and its card is read-only: to move one, use Salesforce Setup → Scheduled Jobs and search for the job name printed at the bottom of its card.

Action What it does Behavior on update
Schedule missing jobs (panel header, and the button on the empty state) Schedules every background job the package expects — the finalizer and heartbeat families, recurring billing, retention purge, refund/dispute reconciliation, the Stripe payment sweep and the nightly campaign-total rebuild Immediate, and safe to click at any time. A job that exists and is running is left exactly as it is, cadence included. A job whose owner no longer resolves — which is every job a fresh install created, since the post-install script runs as a system user the org cannot reach — is aborted and rescheduled under your login. That second behaviour is the whole reason to press this after a fresh install. Same action as Fix on the Health Check row and the Get Started button, which reads "Restart the background jobs" when the jobs exist but are dead. If the panel is empty, this is the only control that can start the schedule — the cadence editor only appears once a family has jobs to edit.
"Run every" cadence + Save (per job family) Reschedules how often the Donation Finalizer / Reconciliation Heartbeat jobs fire Immediate — but this is two separate steps under the hood (abort the old schedule, then create the new one). If the second step fails after the first succeeds, that job family ends up scheduled nowhere until you save again. For the Donation Finalizer family, that means donations stop turning into Opportunities until it's rescheduled — watch for a "0 scheduled" state after a save.
Run now — Recurring donations Manually kicks off the same nightly recurring-billing chain used at 2am Runs immediately, and it is the real thing — it charges every recurring gift due today exactly as the nightly job would, regardless of whether that nightly job is currently scheduled. Not a preview or dry run.
Run now — Donor summary rollups Recalculates donor lifetime-giving totals Immediate; does not trigger any charges
Run now — Retention purge Immediately deletes old logs/transaction logs/completed donation-staging rows Immediate, using whatever "Purge after (days)" value is currently saved on the Logging panel — not restorable afterward
Run now — Refunds and disputes Pulls refunds issued directly in the Stripe dashboard, and any chargeback activity, back into Salesforce Immediate; read-only against Stripe — it records what already happened there and never issues a refund itself. Also runs hourly on its own. Does nothing until Stripe is connected.
Run now — Payment sweep Finds Stripe payments that succeeded but never became a donation record, and finishes them Immediate; re-reads existing payments only, so it cannot double-charge. Also runs hourly on its own. Does nothing until Stripe is connected.
Run now — Campaign totals Recalculates every campaign's raised amount and donor count from its donations Immediate; overwrites the stored totals with what the donations actually say. Use it after a bulk import or any time a campaign's total looks wrong. Also runs nightly on its own.

"Run now" for recurring donations places real charges

This is not a test or preview button. Clicking it charges every donor whose recurring gift is due today, the same as if the nightly job had fired. Each charge is protected from being accidentally repeated on the same schedule the same day (an unchanged charge won't be billed twice), but any schedule not yet charged today will be charged the moment you click this.

Donation Monitor (app tab — no longer a Settings panel)#

A live worklist of donations stuck between "paid on Stripe" and "recorded as an Opportunity" — not settings fields. It lives on the Donation Monitor tab in the app navigation, not in this console; it is documented here because its one action changes records. For the filters and a worked troubleshooting sequence see Monitor donations and read the logs.

Action What it does Behavior on update
Retry now (per row) Re-checks the donation's payment status with Stripe and finalizes/expires it accordingly Immediate. This only re-reads the existing payment's current status from Stripe — it never submits a new charge, so retrying cannot cause a double charge. If the payment actually succeeded but finalizing keeps failing (e.g. a validation rule), the record is deliberately never auto-expired, so retrying repeatedly is safe — it just won't self-resolve until whatever is blocking finalization is fixed.

Next#