Skip to content

Core Concepts

Donors & accounts#

A donor is always a person — a standard Contact or a Person Account, resolved automatically depending on how your org models people. Nothing in Pledgivo hard-codes one or the other.

Two account models, one package#

Salesforce orgs represent individual people one of two ways: the standard Contact/Account pair, or Person Accounts (a single record that's both). Nonprofits and membership orgs are split fairly evenly between the two, so Pledgivo supports both — and detects which one your org uses at install time rather than asking you to choose.

Every donor-related custom object carries two parallel lookup fields:

Field Populated when
Contact__c Your org uses the standard Contact/Account model
Donor_Account__c Your org uses Person Accounts

Exactly one of the two is populated on any given record — never both, never neither. This shows up on Recurring_Donation__c, Payment_Method__c, and every other object that needs to point at a donor.

Never branch on IsPersonAccount yourself

All donor resolution — creating a new donor, matching an existing one by email, deciding which of the two lookup fields to populate — goes through a single service, DonorResolutionService. Application code never checks IsPersonAccount directly. If you're extending the package, route through that service rather than re-implementing the branch.

How a donor gets created or matched#

When a gift comes in through the public donation form, DonorResolutionService looks for an existing donor by email before creating a new one — a returning donor's second gift lands on their existing Contact or Person Account, not a duplicate. The exact matching rule is email-based; donors are not asked to log in to give.

Every donor gets a household Account#

In a Person Account org the donor is an Account, and there is nothing to decide. In a standard Contact/Account org a Contact created on its own would be what Salesforce calls a private contact — a Contact with no Account behind it. That is a real problem rather than a cosmetic one: an Opportunity requires an Account to appear on any Account-related list, and every standard Salesforce report grouped by Account silently drops gifts that have none.

So when a first-time donor gives, the package creates a household Account alongside their Contact, named after them — "Maria Alvarez Household" — and books the gift against it. A returning donor reuses the household their Contact already sits in. A donor who was already in your org without an Account (imported, hand-entered, or created by an earlier release) gets one back-filled on their next gift, once.

Households are matched by donor, never by name

The dedup key is the donor's email, exactly as it always was, and the household simply follows whichever Contact that email resolved to. Accounts are deliberately never matched on name — "Smith Household" would quietly merge every unrelated Smith who ever gave into one household, and nothing in the data says they belong together. If two members of a real household should share one Account, merge them yourself; the package will not guess.

Donations (Opportunities)#

A donation is a standard Salesforce Opportunity, related back to the donor through the standard Contact (via Contact Role or Account) or AccountId in the Person Account case. In a standard org AccountId holds the donor's household (above); in a Person Account org it holds the donor. Either way it is filled, so a gift never falls out of an Account-grouped report. See Donations & payments for the full Opportunity field picture.

Donor-facing self-service#

Returning donors can manage their own recurring gifts, view their giving history, and update a saved payment method through the donor portal — a token-authorized page (no login required; possession of a mailed or emailed link is the access grant). See Publish a donor portal page.

The portal is passwordless, and the only way in is a link the donor requests for themselves. That is the right default and it strands three people: the donor whose link expired, the donor who deleted the email, and the donor who is on the phone with you right now.

Send Portal Link, on the Contact and Account record pages, is the staff-side door into the same flow. It confirms before it issues, showing the address the mail will actually reach — worth reading in a Person Account org, where the address lives on the Account rather than on a contact lookup. Then it offers two ways out, because the support call has two shapes:

  • Send Link emails the link to the donor.
  • Show Link puts the same link on screen with a copy button, for the donor already on the phone — and for the donor with no email address on file at all, who can be handed a link but never mailed one.

Either way the panel stays open afterwards showing the link that was issued, so you can read it out. It is not written to any log.

Issuing a link invalidates the previous one

Both buttons mint a fresh token, and a donor only ever has one live link. If they find the old email after you've issued a new link, the old one will no longer work — so tell them to use the one you just sent. That's also why the buttons become Done once used rather than staying pressable: pressing again would quietly invalidate the link you just handed over.

Giving history on the donor's page#

The donor's record page carries a giving statement card — the same annual summary a donor can pull for themselves, on the record a fundraiser is already looking at. It's on both the Contact and the Person Account page, so it's there whichever account model your org runs. See Annual giving statements.

Assign the donor layouts per record type

The Donor page layout (Contact) and Donor Organization layout (Account) are assigned by record type, not globally. If a donor record shows the stock Salesforce layout instead of the one the package ships, check the layout assignment for that record type under Setup → Object Manager → Page Layouts → Page Layout Assignment — assigning it for one record type leaves the others untouched.

  • Donations & payments

    Opportunity fields, payment status, and how a gift gets confirmed.

    Read more →

  • Recurring giving

    Saved payment methods and self-managed billing schedules.

    Read more →

  • Full object reference

    Every donor-related field, across every object.

    Browse the data model →