NPSP Migration Decisions · AD-9

Do household members’ automatic contact roles become Gift Soft Credits?

NPSP automatically gives every household member a contact role on a household gift. If those automatic roles all became Gift Soft Credits[1] in the target, household recognition reports would count them as if they were deliberately entered recognition — a silent inflation. The alternative rebuilds household-level recognition from household membership instead of from soft credits.[2]

Talk to an Architect All 16 decisions

Who decides

Fundraising lead

Decide after

MD-1 (household model)

Estimated effort

S  check the recognition reports

What answers it

NPSP’s household soft-credit settings, and the recognition reports that read soft credits today.

Your options, and what each one does

The Options
The optionWhat it means for the migration
Household members’ automatic roles are not soft creditsGift Soft Credits carry only the roles NPSP’s own setting names as soft credits. Household-level recognition in reports is rebuilt from household membership.
Household members’ automatic roles become Gift Soft CreditsAutomatic roles on won gifts load as Gift Soft Credits as well. Household recognition reports keep reading soft credits, as they do in NPSP.

What Horus Eye recommends — and when

Recommendation, Not Verdict

Keep automatic household roles out of soft credits — they are created by NPSP for every household gift, not entered as recognition. What would change it: recognition reports that genuinely rely on household members’ soft credits and cannot be rebuilt from membership.

A recommendation is a starting point, not a verdict. The same question lands differently org by org — one fact about your automation, volumes or vendors can flip the right answer. That is why the reasons are stated, and what would change them.

How this decision plays out

In Practice

The mechanism matters here: NPSP automatically gives every member of a household a contact role on each household gift. Nobody typed those roles in; they are plumbing. If migration converts them all into Gift Soft Credits, the target fills with recognition records nobody deliberately created — and household recognition reports count them as if a human had decided each one. That is the silent inflation this decision exists to prevent: recommended practice routes only the roles NPSP’s own settings designate as soft credits, and rebuilds household-level recognition from household membership, where it actually lives in the new model.

The counter-case is operational, not technical: some fundraising teams have built recognition societies, stewardship tiers or donor-wall logic directly on household members’ soft credits, and those reports would need redesign if the automatic roles stop arriving. If that is you, migrating them is a defensible recorded choice — made with eyes open about what the counts will mean. Either way, test the outcome the way a donor would experience it: pick three real households, work out by hand what recognition each member should show, and compare against a trial load. Recognition is one of the few data categories donors personally notice; it deserves a hand check.

Questions to settle before you record an answer

Before You Decide
The decision register listing recorded answers with who decided and when
Recognition choices on the record: the soft-credit answer lands in the decision register like every other (example data).

How Horus Eye helps

With Horus Eye

When Horus Eye assesses an NPSP org, this question is raised with the evidence the scan saw — the record types, fields and settings behind it — its recommendation marked, and the reasons stated. Accept records the recommendation; Change opens the options. Recording an answer writes nothing to Salesforce: it is captured in the decision register, with who decided and when, and the migration plan, mappings and documents are kept consistent with what your organization actually decided. Horus Eye recommends; your organization decides.

Sources & further reading

References

Protected AI — the Trust Layer

Every AI read in Horus Eye is metadata-first: built from an allowlist, sanitized by pattern, made through one audited gateway and checked by an output firewall on the way back — and AI is off by default, per org. Every request carries an audit id and an AI Data Scope manifest you can open.

See the Trust Layer

Facing this decision in your own org?

Horus Eye

A read-only assessment puts the evidence behind it on the table — what your org holds, what it means for this choice, and the decisions that depend on it.

Try Horus Eye Free Request an Assessment All Horus Eye pages

Free start · 250 credits for 60 days · no card required · scans are free