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]

Talk to an Architect All 16 decisions

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 optionWhat it means for the migration
Bypassed for the migration user, on after the loadThe 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 loadEvery 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 Verdict

Bypass 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 Practice

The 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
The Decide stage: each question with its recommendation marked, including shared e-mail resolution
Identity decided once, before the load: shared-e-mail groups resolved as recorded decisions (test org).

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