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 - Can be customized via integration settings
  • 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. Organization Accounts - Companies and organizational donors (non-household)
  2. Household Accounts - Family/household groupings of individual contacts The integration handles both types through the Account object, using Record Types to distinguish between them.

​
Standard Field Mappings

​
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.
Household addresses: Households typically do not sync address information at the Account level in this integration. 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 default 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. This corrects a prior version of this page, which stated that Account state and country always sync both ways and are not subject to picklist validation. They are subject to the same org-wide picklist validation as Contact. 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

​
Record Type Assignment

The integration automatically assigns the appropriate Record Type based on whether the Account represents a company or a household: For Companies:
  • Record Type is determined by the non_household_record_type_name setting (default: “Organization”)
  • The Type field is automatically set to “Organization” For Households:
  • Record Type is determined by the household_record_type_name setting (default: “Household Account”)
  • The Type field is not set (households typically do not have a Type value)

​
Primary Contact Linking

For Companies: The npe01__One2OneContact__c field links the Account to a primary Contact in Salesforce. This field is only set during account creation and follows the NPSP model for organization contacts. After creation, this relationship cannot be changed via the integration. On create, if the company donor in WeGive has an associated user (logged in previously), the integration finds the primary individual donor linked to that user, sets npe01__One2OneContact__c to that individual’s Salesforce Contact ID, and copies the primary individual’s email addresses to the company donor record. For Households: The npe01__One2OneContact__c field identifies the primary member of the household. On import, WeGive finds the Contact whose salesforce_id matches the value in npe01__One2OneContact__c, marks that Contact as the primary household member, and adds all other Contacts with the same AccountId as household members. On export, WeGive sets npe01__One2OneContact__c to the Salesforce ID of the primary household member.

​
Email Inheritance from Primary Contact (Companies Only)

When a company donor is created in Salesforce and has a primary contact (via user login relationship), the integration automatically copies email addresses from the primary individual donor to the company donor (email_1, email_2, email_3). This ensures the organization has 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.

​
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 automatic Type assignment and RecordType selection).