← All insightsCRM planning

NPSP donor relationships for faith-based nonprofits

Map people, households, congregations and gifts before changing the CRM. A useful donor model preserves relationships without counting the same contribution several times.

Confirm which nonprofit product you use

Begin with the actual Salesforce configuration. Nonprofit Success Pack (NPSP) has its own data model; do not assume an instruction written for another Salesforce nonprofit product applies unchanged. Use your installed product and configuration to guide the design.

Draw a few representative situations before editing fields: an individual donor, two people in one household, a person associated with a congregation and a gift from an organisation. Have fundraising and data owners agree what each relationship means.

Use each relationship for its intended purpose

In NPSP, Contacts represent people and Accounts represent households or organisations. An Affiliation connects a Contact to an Organisation Account. A Relationship connects one Contact to another. A congregation’s place within a wider organisation is a separate modelling question; it is not the same thing as a person’s affiliation.

Salesforce Trailhead: the NPSP data model

Salesforce: create an affiliation with an organisation

Questions to settle before an import
QuestionDecision to record
Who gave?The donor record that owns the contribution.
Who is connected?Household, personal and organisational relationships, represented separately.
Who receives recognition?The recognition or soft-credit rule, without duplicating the actual gift.
Which organisation is relevant?Whether reporting uses the current affiliation or the affiliation at the time of the gift.
Who may see the information?Permissions appropriate to fundraising, finance and other roles.

Keep gift ownership separate from recognition

A contribution and the people or organisations recognised for it are not interchangeable records. Agree how reports total actual giving and how they display recognition. Test a gift with more than one recognised person so the same amount is not counted again as new revenue.

Do not change donor ownership solely to make a grouping report easier. A reporting requirement may need an explicit historical attribute or a different report design rather than moving the contribution to another account.

Preserve the meaning of history

A person may move household or change organisational affiliation. Decide whether a historical campaign report should reflect the relationship at the time or the person’s current relationship. If you need both, describe them separately and keep the required history.

Use a small synthetic example to demonstrate that behaviour before importing years of records. A report that looks correct for today’s members can still misrepresent earlier giving.

Match carefully and rehearse the import

Shared email addresses do not prove that two donor records describe the same person. Agree matching and merge rules, retain the old identifiers and hold uncertain matches for a data owner. Check how connected gifts and relationships behave before merging anything.

  • Create a mapping for people, accounts, relationships and contributions.
  • Rehearse representative records, including shared households and multiple affiliations.
  • Reconcile counts, gift totals and selected relationships against the source.
  • Check access with the actual staff roles.
  • Record exceptions, the cutover process and how to recover from an incorrect import.

Limit sensitive relationship data

Collect the information needed for the organisation’s work and define who can access it. Religious affiliation and personal relationships deserve deliberate handling. A system that can store a detail does not establish a business reason to collect or share it.

The useful outcome of discovery is an agreed model, sample records, report definitions and an import plan. This guide supplies no migration duration, duplicate-prevention count or customer result.

Explore nonprofit operations

Discuss a similar workflow

Bring a description of the process, the systems involved and one example of where work gets stuck. We can use discovery to establish the requirements, dependencies and next step before preparing a solution and estimate. Please leave private customer, applicant and patient records out of the website enquiry.

Discuss your requirements

Explore CRM integration services ↗
YOUR FIRST STEP / 30-MINUTE DISCOVERY CALL

Bring one process you want to improve.

In a 30-minute discovery call, we will walk through the problem, the systems involved and what a useful result looks like. Then we agree the next step toward a scoped approach and estimate.

Book a discovery callPrefer to write? Send a project enquiry →With Nigam Goyal · Google Meet