How New Supporters Sync to Salesforce NPSP

When someone donates through a WeGive checkout for the first time, the integration needs to decide: does this person already exist in Salesforce, or do we need to create a new record? The answer depends on whether the supporter is an individual (syncs to a Contact) or a company (syncs to an Account) — and the matching logic is different for each.

The Two Scenarios

Scenario 1: A New Individual Donates via Checkout

What the donor does: Jane Smith fills out a checkout form, enters her name, email, and payment info, and completes a $50 donation. She's never given through WeGive before.

What WeGive does in Salesforce:

1. The donation completes and WeGive queues the sync (roughly 5-minute delay)

2. Before creating anything, WeGive searches Salesforce: "Is there already a Contact with this email address?"

3. If a match is found → WeGive links to the existing Contact and updates it with the incoming data

4. If no match is found → WeGive creates a new Contact, and NPSP automatically creates a Household Account for them

5. Then the donation syncs as an Opportunity and Payment under that Contact

Scenario 2: A New Company Donates via Checkout

What happens: Acme Corp makes a $1,000 donation through checkout. The company has never given through WeGive before.

What WeGive does in Salesforce:

1. The donation completes and WeGive queues the sync

2. WeGive does not search for an existing Account — there is no matching logic for companies

3. WeGive creates a new Account in Salesforce with the Record Type "Organization" (or whatever your org has configured)

4. Then the donation syncs as an Opportunity and Payment under that Account

Key difference: Individuals get email-based matching. Companies do not get any matching — a new Account is always created.

Individual Matching: How It Works Step by Step

When WeGive is about to push an individual donor to Salesforce, it runs through this decision tree:

Step 1: Does the donor have an email?

If the donor's primary email (email_1) is blank, matching is skipped entirely and a new Contact is always created. No lookup happens.

Step 2: Search Salesforce by email

WeGive queries Salesforce:

"Give me all Contacts where Email = jane.smith@email.com, sorted by most recently modified."

This is an exact email match only. WeGive does not match on name, phone, address, or any other field — just email.

Step 3: Was a Contact found?

If no Contact has that email → WeGive creates a new Contact in Salesforce. NPSP auto-creates a Household Account. Done.

If multiple Contacts have that email → WeGive picks the one with the most recent LastModifiedDate — not the most recently created, but the most recently modified. Any field update on a Contact counts as a modification, so a bulk data cleanup, an automation rule firing, or even a manual edit to an unrelated field could change which Contact WeGive selects. This is worth knowing if your Salesforce org has duplicate Contacts with the same email address.

If a Contact with that email exists → Go to Step 4.

Step 4: Is that Salesforce Contact already claimed by another WeGive donor?

This is the duplicate prevention check. WeGive looks at its own database: "Do I already have a different donor record linked to this Salesforce Contact ID?"

• If no other WeGive donor is linked to it → WeGive links to the existing Contact and updates it with the new donor's data. No duplicate created.

• If another WeGive donor IS already linked to it → WeGive intentionally creates a new Contact in Salesforce, even though the email matches. This prevents one WeGive donor's updates from overwriting another's data.

What Gets Created

When a new Contact is created, the following default fields are set:

State and country fields are not set by default due to Salesforce picklist conflicts — these can be mapped through custom Mapping Rules if needed.

After the Contact is created, WeGive retrieves the auto-created Household Account ID from Salesforce and stores it. If the donor belongs to a WeGive Household, that Household is linked to the Salesforce Household Account.

What Gets Updated (on a match)

When WeGive matches to an existing Contact, it updates all of the same fields listed above. The existing Contact's data is overwritten with whatever WeGive has for that donor.

Company Matching: There Is None

Company donors follow a simpler path: WeGive always creates a new Account. There is no lookup, no email matching, no name matching. Every company donor pushed from WeGive results in a brand new Account record in Salesforce.

What Gets Created

Why This Matters

If the same company already exists as an Account in Salesforce — say, "Acme Corp" was entered manually by a fundraiser last year — WeGive will create a second "Acme Corp" Account. This is a known behavior, not a bug.

How to handle it:

• Use Salesforce's built-in duplicate rules to catch and merge duplicates after they're created

• Manually merge the Accounts in Salesforce after the sync

• If the company will be a repeat donor, merge the duplicates once and future donations will sync to the correct Account going forward

Timing and Order of Operations

Here's the full sequence when someone donates through checkout for the first time:

1. Donor completes checkout → WeGive creates a Donor record and a Transaction record

2. Sync is queued → The push to Salesforce happens with a ~5 minute delay, allowing related data to settle

3. Donor syncs first → WeGive checks if the donor needs a Salesforce record

   • Individual with no salesforce_id → runs matching logic → creates or links Contact

   • Company with no salesforce_account_id → creates new Account (no matching)

4. Transaction syncs second → The donation pushes as an Opportunity with a Payment record, linked to the Contact or Account from step 3

5. Related data syncs → GAU Allocations, Campaign links, Recurring Donation references all sync after

The donor must sync before the transaction because the Opportunity needs a Contact or Account to attach to.

Edge Cases and Common Questions

"The donor used a different email than what's in Salesforce"

WeGive matches on exact email only. If Jane Smith is in Salesforce as jane@company.com but donates using jane.smith@gmail.com, WeGive will not find the match. A new Contact will be created. You'll need to merge the duplicates in Salesforce manually.

"There are multiple Contacts in Salesforce with the same email"

WeGive picks the one that was most recently modified (LastModifiedDate DESC). This is not the same as most recently created — any field change on a Contact updates its LastModifiedDate. Be aware that bulk updates, automation rules, or even a manual edit to an unrelated field on an older Contact could cause WeGive to start matching to a different record. If you have known duplicates in Salesforce, merging them before they cause unexpected matching behavior is recommended.

"The donor didn't provide an email"

No matching is attempted. A new Contact is created every time. The Contact will have a blank Email field.

"Two WeGive donors have the same email"

The first donor to sync will claim the Salesforce Contact. The second donor will create a new Contact (intentional duplicate) to prevent data from being mixed between the two WeGive records.

"A company donor has the same name as an existing Salesforce Account"

WeGive will still create a new Account. Company matching does not exist — not by name, email, or any other field.

"We merged Contacts in Salesforce — will WeGive know?"

It depends on how the merge was done. If the merge was performed using Salesforce's standard merge tool, the losing record gets a MasterRecordId field pointing to the winning record. WeGive recognizes this and updates its reference. If a third-party merge tool was used that doesn't set MasterRecordId, WeGive won't detect the merge and may have a stale reference.

"Can we change the matching to use name instead of email?"

No. The matching logic is email-only and not configurable. This is hardcoded in the integration.

"The Record Type for company Accounts is wrong"

Check the Non-Household Record Type setting in your Salesforce Integration configuration. This controls which Record Type is assigned to company Accounts. The default is "Organization" — if your Salesforce org uses a different Record Type name, update this setting.

Summary