Skip to main content
Mapping between WeGive Donors and Salesforce Accounts
Salesforce Object: Account WeGive Models:
  • Donor (type: company)
  • Household (type: family)

​
How Account Data Syncs

This page shows the fields that sync between WeGive and Salesforce for company/organization donors and household accounts. Direction:
  • Import from Salesforce - Data imports from Salesforce into WeGive only
  • Export to Salesforce - Data exports from WeGive to Salesforce only
  • Both Ways - Data syncs in both directions
Mapping Types:
  • Configurable - Provided by a mapping rule that can be customized in the integration settings
  • Configurable (mapping rule) - Reaches Salesforce only if a mapping rule references it; there is no built-in default
  • Hard-coded - Built into the integration logic and cannot be changed

​
Account Types in NPSP

In Salesforce NPSP, the Account object is used for two distinct purposes, differentiated by Record Type:
  1. Household Accounts - Family/household groupings of individual Contacts. These map to WeGive Households.
  2. All other Accounts - Companies and organizational donors. These map to WeGive company donors.
The integration identifies Household Accounts by the record type named in the household_record_type_name setting (default Household Account). Everything else is treated as a company:
  • Household pull selects Accounts whose RecordTypeId equals the household record type.
  • Company pull selects Accounts whose RecordTypeId is not the household record type. It does not restrict companies to the non_household_record_type_name record type, so any non-household Account (for example a custom “Ministry Unit” record type) is pulled as a company.
  • Deleted company pull does use the non_household_record_type_name record type (default Organization), so deletions of Accounts with other record types are not propagated.
If the household record type cannot be found in the org, household and company pulls stop with an error.
Households are not pushed to Salesforce by this integration. WeGive never inserts or updates a Household Account. A WeGive household receives its Salesforce ID from the Account that NPSP creates automatically when WeGive inserts a Contact; see Household Salesforce ID origin.

​
Company Field Mappings

Unlike Contact, there are no hard-coded address exports for Account. Address fields reach Salesforce only through mapping rules. Street lines are not concatenated for Account.

​
Address field pairing

Account uses different address field names than Contact:
  • Billing Address on Account = primary business address, paired with WeGive billing_address
  • Shipping Address on Account = secondary/mailing address, paired with WeGive mailing_address
This differs from Contact, which pairs Mailing Address (primary) with WeGive mailing_address and Other Address (secondary) with WeGive billing_address. On import, address values that come back empty are stored as empty strings. When a company is created from Salesforce, both a mailing and a billing address row are always created, even if no address fields are mapped. Household addresses: Households do not sync address information at the Account level. The household pull requests only Id, Name, RecordTypeId, CreatedDate, LastModifiedDate, the primary contact column, and any fields referenced by household import rules. Address information is maintained at the Contact (household member) level.

​
State and Country Picklists

Salesforce State and Country/Territory Picklists is an org-wide setting. When it is enabled, it applies to the Account object as well as the Contact object. The Billing and Shipping state and country fields become paired fields: a code field (BillingStateCode, BillingCountryCode, ShippingStateCode, ShippingCountryCode) that stores the validated ISO code, and a read-only display field (BillingState, BillingCountry, ShippingState, ShippingCountry) that shows the full name. Because of this, the both-ways mappings to the display fields shown in the table above only apply to free-text (non-picklist) orgs. For orgs with picklists enabled, Account state and country require the same two one-directional rule pattern used for Contact: export the WeGive code accessor to the Salesforce code field, and import the Salesforce code field into the writable WeGive value column. State and country mapping for picklist-enabled orgs (Account): The split is required because the WeGive value field (state, country) is the writable column, while the code accessor (state_code, country_code) is read-only and derives the ISO code from the stored value. Exporting from the code accessor sends a valid ISO code that the restricted picklist accepts; importing into the value field lets the incoming code land in a writable column. A single both-ways rule cannot serve both directions. For the customer-facing setup walkthrough (including the equivalent Contact mapping and how to remove conflicting rules), see Configuring Salesforce State and Country Picklist Mappings in the Knowledge Base.

​
Household Field Mappings

Households are import only. Every field below flows from Salesforce into WeGive; nothing is written back to the Household Account. Additional Salesforce fields can be imported into households through household import mapping rules. Values that do not correspond to a household column are stored as custom field values.

​
Household Salesforce ID origin

A WeGive household gets a salesforce_id in one of two ways:
  1. Pulled from Salesforce. A Household Account pulled from Salesforce creates or updates a WeGive family household with that Account’s Id.
  2. Captured after a Contact insert. When WeGive inserts a new Contact, NPSP automatically creates a Household Account for it. WeGive reads the Contact back, stores its AccountId on the donor as salesforce_account_id, and, if the donor belongs to a WeGive family household that has no salesforce_id yet, sets the household’s salesforce_id to that Account ID.
There is no third path. Household name changes, membership changes, and primary member changes made in WeGive are not sent to Salesforce.

​
Company Pull and Matching

Pulling companies is enabled by the Pull companies toggle under Sync Configuration. The pull column defaults to LastModifiedDate and can be changed with the pull_by setting. For each non-household Account returned, WeGive:
  1. Looks for an existing company donor with a matching salesforce_account_id.
  2. If none is found and the mapped data includes an email_1 value, looks for a company donor with the same email_1 that has no salesforce_account_id yet, and links it.
  3. Otherwise creates a new company donor.
  4. Applies email inheritance, mapped fields, custom fields, and address blocks, then saves without triggering an outbound push.

​
Company Push

Pushing companies is enabled by the Push donors toggle under Sync Configuration. When a company donor has no salesforce_account_id, WeGive inserts a new Account; otherwise it updates the existing Account by ID. There is no email or name based search for an existing Account before insert, unlike the Contact push. A short-lived lock prevents concurrent pushes of the same company from creating duplicate Accounts. After a successful insert, if the company donor was created by a logged-in user, WeGive finds that user’s most recently used individual donor in the same organization and sets that individual’s salesforce_account_id to the new Account ID. No email addresses are copied during push.

​
Record Type Assignment

For Companies:
  • On create, RecordTypeId is looked up by name using the non_household_record_type_name setting (default Organization) and Type is set to Organization, unless a per-subtype Salesforce Account Type override applies — see Account Type and Company Subtypes below.
  • On update, RecordTypeId is never sent, so record types assigned in Salesforce are never overwritten by WeGive. Type is likewise never sent on update unless a per-subtype override is configured for the donor’s company subtype (again, see below) — in that case the configured value is sent on both create and update.
For Households:
  • Households are never created or updated by WeGive, so no record type is assigned. The household_record_type_name setting (default Household Account) is used only to select which Accounts are pulled as households.

​
Account Type and Company Subtypes

Each of an organization’s configured company subtypes (OrganizationCompanyType) can optionally be assigned a Salesforce Account.Type picklist value via a salesforce_account_type column, set through the dashboard’s Company Types settings. This is independent of, and takes precedence in the payload over, the plain hard-coded 'Organization' default described above — but explicit field-mapping rules configured for Type still take precedence over this subtype-based value. RecordTypeId behavior is unaffected by this feature and follows the rules in Record Type Assignment unchanged. Push (export): If the donor’s company subtype has a non-blank salesforce_account_type value configured, that value is sent as Type on both create and update — this is the one case where Type is sent on update. If no value is configured for the subtype, the legacy behavior applies: 'Organization' on create only, and Type omitted entirely on update. Pull (import): On company pull, WeGive now also selects the Salesforce Type field. Incoming Type values are matched against the organization’s own active company subtypes by their configured salesforce_account_type. A subtype is only assigned back to the donor when exactly one active subtype in that organization matches the incoming value — a blank/missing Type, no match, or more than one active subtype configured with the same salesforce_account_type value all leave the donor’s existing subtype classification untouched (or the donor unclassified, if new). Subtype resolutions are cached per distinct Type value for the duration of a single pull run. salesforce_account_type is a CRM-internal value and is never exposed in the subtype shape sent to donors (checkout, portal, signup).

​
Primary Contact Linking

For Companies (export): There is no hard-coded export of npe01__One2OneContact__c. When compiling the Account payload, WeGive determines a primary individual as follows: if the company donor was created by a logged-in user, the user’s most recently used individual donor in the same organization is the primary individual, and that individual’s salesforce_id is offered to mapping rules as salesforce_contact_id. The Account only receives this value if an export mapping rule maps salesforce_contact_id to npe01__One2OneContact__c (or another field). When such a rule exists, the value is sent on both create and update. For Companies (import): The value of the primary contact column on the Account is resolved to the WeGive individual donor with that salesforce_id. It is used only for email inheritance (below) and is not stored on the company donor. For Households (import): WeGive finds the individual donor whose salesforce_id matches the primary contact column value and whose salesforce_account_id matches the Household Account, and marks that donor as the household’s primary member. When a household is first created from Salesforce, all individual donors whose salesforce_account_id equals the Account Id are added as members. After that, membership is maintained by the Contact pull: a Contact whose AccountId points at the household is attached to it (and removed from any previous household) when it is imported.

​
Email Inheritance from Primary Contact (Companies Only)

This happens on import, not on push. When a non-household Account is pulled and its primary contact column points to a Contact that is linked to a WeGive individual donor, the company donor’s email_1, email_2, and email_3 are overwritten with that individual’s values before the rest of the mapped data is applied. This gives the organization contact information even though email fields are not standard on the Account object. This does not apply to households, where contact information is maintained through the household members’ Contact records. Nothing is copied when the Account is pushed from WeGive.

​
Merged Accounts

The integration detects Accounts merged in Salesforce by pulling Accounts whose MasterRecordId is set (always filtered by LastModifiedDate, regardless of the pull_by setting). For each merged pair:
  • If both the losing Account and the master Account are linked to WeGive company donors (by salesforce_account_id), the two company donors are merged in WeGive, with the master’s donor surviving.
  • Otherwise, if both are linked to WeGive family households (by salesforce_id), the two households are merged in WeGive.
  • If only one side is linked, or the pair mixes a company and a household, nothing happens.

​
Deleted Accounts

  • If pull_deleted_households is enabled, Household Accounts with IsDeleted = true in the sync window delete the matching WeGive household (matched by salesforce_id).
  • If pull_deleted_companies is enabled, Accounts of the non_household_record_type_name record type with IsDeleted = true delete the matching WeGive company donor (matched by salesforce_account_id).
Accounts not linked to a WeGive record are ignored. Both pulls stop with an error if the expected record type name cannot be found in the org.

​
Understanding Configurable vs Hard-coded

  • Configurable mappings can be customized through integration settings if needed for your organization’s specific field setup.
  • Hard-coded mappings are built into the integration’s core logic and handle special business rules (like Type and RecordType assignment on create).

​
Settings Reference

Verified against the integration source, September 2026.