NPSP Migration Decisions · AD-7
Do duplicate and matching rules run while the migration loads?
Salesforce duplicate rules guard identity — and identity should be decided once, in the review before the load: which records that share an e-mail address are the same person, and which are different people. If the target’s duplicate rules run during the load, a legitimate record can be blocked or flagged mid-load, a load step stops without reconciling, and the identity review is effectively repeated against the rules’ own matches.[1]
Who decides
Data owner with the Salesforce administrator
Decide after
No prerequisite — decide in parallel
Estimated effort
M the identity review is the real work
What answers it
The state of the identity review — shared-e-mail groups resolved or not — and the matching rules planned for the target.
Your options, and what each one does
The Options| The option | What it means for the migration |
|---|---|
| Bypassed for the migration user, on after the load | The reviewed identity pairs load as the review decided, without the target re-flagging or blocking them. Matching rules for Person Accounts[2] are switched on before the teams start entering records. |
| On during the load | Every load row faces the rules; blocks and flags mid-load are handled as they come. Only defensible when the identity review could not be finished first. |
What Horus Eye recommends — and when
Recommendation, Not VerdictBypass for the migration user, then switch on — identity decided once, in the pre-load review, with the target’s rules guarding new entries from day one. The unfinished-review case is the exception that changes the answer. Salesforce duplicate rules exist to protect data quality; the question is only when they run.
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 PracticeThe principle underneath this one: identity should be decided exactly once, by humans, before the load — not re-litigated row by row, mid-load, by a matching rule. Nonprofit data makes the point sharply: spouses sharing an e-mail address, families giving through one account, generations of slightly-different name spellings. The pre-load identity review resolves each of those groups — same person, or different people — with the context a rule cannot have. If the target’s duplicate rules then run against the migration user, they second-guess that finished review: legitimate records get blocked or flagged mid-load, a load step stops without reconciling, and the team ends up doing identity twice under worse conditions.
Hence the standard choreography: duplicate and matching rules bypassed for the migration user only, loads run against a settled identity map, and the rules switched on — tuned for Person Accounts — before real users start entering records. The honest exception is an unfinished review: if shared-e-mail groups are still unresolved when the load window arrives, rules-on is the safety net you chose by not finishing — slower and noisier, but safer than loading unreviewed identities at speed. The better plan is simply to finish the review first; it is also the item on the critical path most often underestimated.
Questions to settle before you record an answer
Before You Decide
How Horus Eye helps
With Horus EyeWhen 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- 1.
Salesforce · Agentforce Nonprofit Migration Guide v2.0 (PDF) — The official guide this content follows: platform differences, migration recommendations, and how NPSP features map to Agentforce Nonprofit. ↩︎ - 2.
Salesforce Help · Enable Person Accounts for Fundraising — The enablement step — and why it is planned, not casual: Person Accounts cannot be disabled once enabled. ↩︎
“Salesforce”, “Agentforce” and related marks are the property of Salesforce, Inc. Horus Eye is an independent product and is not affiliated with, endorsed, or sponsored by Salesforce, Inc.
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.
Facing this decision in your own org?
Horus EyeA 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 pagesFree start · 250 credits for 60 days · no card required · scans are free