Syncing Only Contacts With Email Addresses: What to Expect
Last updated: August 14, 2026
WeGive's Salesforce integration includes a setting that limits the contact sync to Salesforce Contacts that have an email address. Contacts with a blank email are excluded from the pull.
This article explains what that setting affects, why it makes your integration logs difficult to interpret, and what to consider before enabling it.
Our recommendation is to leave this setting off. The sections below explain why.
What the Setting Does
When enabled, WeGive pulls only Salesforce Contacts that have a value in the email field. Contacts with a blank email are not created as supporters in WeGive.
Salesforce Accounts are not affected. Organization and household records continue to sync regardless of whether they have an email address.
What Else Stops Syncing
This is the part that surprises most organizations. The setting is described in terms of contacts, but its effect reaches every record that depends on a contact.
When a contact is excluded, WeGive has no supporter record to attach that contact's activity to. Anything owned by that contact is skipped as well.
Records affected when a contact is excluded:
Record type | What happens |
Gifts and donations | Do not import. The gift history for that donor is absent from WeGive. |
Recurring donations | Do not import. WeGive has no plan record, so the commitment cannot be managed or billed through WeGive. |
Soft credits | Do not import if either the paying donor or the credited donor was excluded. |
Campaign membership | Does not import, so campaign reporting undercounts. |
Fund allocations and designations | Do not import, because the gift they belong to is not there. |
The recurring donation impact is the one worth pausing on. If your organization intends to move offline or manually processed recurring gifts onto WeGive, and some of those donors have no email address on file, those commitments cannot be migrated while this setting is on.
Why Your Integration Log Becomes Hard to Read
This is the most significant consequence, and the main reason we advise against the setting.
When a record is skipped because its contact was intentionally excluded, WeGive currently records it as an error, not as a skip. The integration log shows a failure count that mixes two very different things:
Records that failed for a real reason and need attention
Records that were excluded exactly as you configured
There is no way to tell them apart from the log.
Messages you will see in this situation:
Message | What it usually means |
| The gift's contact was excluded, so there is no supporter to attach it to. |
| The recurring donation's contact was excluded. |
| The campaign member's contact was excluded. |
| The gift the soft credit points at was not imported. |
| The gift the designation belongs to was not imported. |
What this looks like in practice
One organization enabled this setting with roughly 56% of their Salesforce contacts missing an email address. Their full sync completed successfully and reported approximately 1.1 million errors.
Almost all of those were expected exclusions. The problem was that a genuine, unrelated sync fault was sitting inside that number, and it took a full day of analysis to separate the two. Nobody reviewing the log could have spotted it, because a real failure of any size looks identical to configured behavior.
That is the practical cost. Once the error count is dominated by intentional exclusions, the log stops functioning as a health check. You can no longer glance at a sync result and know whether anything is wrong.
Before You Turn It On
If you are considering this setting, size the impact first. Three queries in Salesforce will tell you most of what you need to know.
Queries to run before enabling:
What to count | Why it matters |
Contacts where Email is blank | The share of your database that will not sync. |
Opportunities whose Contact has a blank email | The share of gift history that will not import. |
Open recurring donations whose Contact has a blank email | Active commitments that cannot be managed in WeGive. |
The third query is the one to look at hardest. Add up the annual value of those recurring donations. That figure is revenue you will not be able to process through WeGive while the setting is on.
Our Recommendation
Leave the setting off.
The reason organizations usually want it is to avoid importing large numbers of contacts with no email address, often older records with no recent activity. That is a reasonable goal, but this setting is a costly way to achieve it:
It removes those contacts' entire gift history along with the contacts themselves, which affects reporting totals
It blocks recurring commitments you may later want to migrate
It makes your sync logs unreliable as a monitoring tool, permanently, not just during setup
If your concern is that contacts without emails will clutter your supporter list or be included in messaging, those are better handled inside WeGive. Supporters without an email address cannot receive email regardless, and list segmentation gives you control over who is contacted without discarding the underlying records.
If the Setting Is Already On
You do not need to change anything immediately. Records are excluded, not deleted, and turning the setting off allows the excluded records to import on the next sync.
Suggested approach:
Run the three sizing queries above so you know what is currently excluded
Check whether any active recurring donations are among the excluded records, and prioritize those
Turn the setting off and run a full sync
Compare the error count before and after. The remaining errors are the ones that warrant investigation
Note that a full sync on a large database can take several hours, so plan it for a period when a long-running job is acceptable.
Getting Help
If you are unsure whether this setting is right for your organization, or you want help interpreting your current sync results, reach out to your WeGive contact before making the change. We can review your error log with you and identify which failures are configured behavior and which are not.