Mapping between WeGive Donors and Salesforce AccountsSalesforce 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:- Organization Accounts - Companies and organizational donors (non-household)
- 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
| Salesforce Field | WeGive Field | WeGive API Field | Direction | Type | Notes |
|---|---|---|---|---|---|
| Id | Salesforce Account ID | salesforce_account_id | Import from Salesforce | Hard-coded | Salesforce’s unique identifier for this account |
| Name | Company Name | name | Both Ways | Configurable import, Hard-coded export | |
| Type | Organization Type | Static: ‘Organization’ | Export to Salesforce | Hard-coded | Always set to ‘Organization’ to distinguish from Household accounts |
| RecordTypeId | Record Type | Dynamic | Export to Salesforce | Hard-coded | Queried from RecordType based on non_household_record_type_name setting |
| npe01__One2OneContact__c | Primary Contact Salesforce ID | salesforce_contact_id | Both Ways | Configurable | Create only; links to primary contact |
| primaryContactColumn | Primary Donor ID | primary_donor_id | Import from Salesforce | Hard-coded | Maps to WeGive donor record |
| Phone | Office Phone | office_phone | Both Ways | Configurable import, Hard-coded export | |
| Fax | Fax | fax | Both Ways | Configurable import, Hard-coded export | |
| BillingStreet | Billing Address - Street | billing_address.address_1 | Both Ways | Configurable | |
| BillingCity | Billing Address - City | billing_address.city | Both Ways | Configurable | |
| BillingState | Billing Address - State | billing_address.state | Both Ways | Configurable | Free-text orgs only. Orgs with State/Country Picklists enabled must use the code-field mapping in State and Country Picklists below. |
| BillingPostalCode | Billing Address - Zip Code | billing_address.zip | Both Ways | Configurable | |
| BillingCountry | Billing Address - Country | billing_address.country | Both Ways | Configurable | Free-text orgs only. See State and Country Picklists below. |
| ShippingStreet | Mailing Address - Street | mailing_address.address_1 | Both Ways | Configurable | |
| ShippingCity | Mailing Address - City | mailing_address.city | Both Ways | Configurable | |
| ShippingState | Mailing Address - State | mailing_address.state | Both Ways | Configurable | Free-text orgs only. See State and Country Picklists below. |
| ShippingPostalCode | Mailing Address - Zip Code | mailing_address.zip | Both Ways | Configurable | |
| ShippingCountry | Mailing Address - Country | mailing_address.country | Both Ways | Configurable | Free-text orgs only. See State and Country Picklists below. |
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_addressThis differs from Contact, which pairs Mailing Address (primary) with WeGivemailing_addressand Other Address (secondary) with WeGivebilling_address.
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):
| Salesforce Field | WeGive API Field | Direction | Type |
|---|---|---|---|
| BillingStateCode | billing_address.state_code | Export to Salesforce | Configurable |
| BillingStateCode | billing_address.state | Import from Salesforce | Configurable |
| BillingCountryCode | billing_address.country_code | Export to Salesforce | Configurable |
| BillingCountryCode | billing_address.country | Import from Salesforce | Configurable |
| ShippingStateCode | mailing_address.state_code | Export to Salesforce | Configurable |
| ShippingStateCode | mailing_address.state | Import from Salesforce | Configurable |
| ShippingCountryCode | mailing_address.country_code | Export to Salesforce | Configurable |
| ShippingCountryCode | mailing_address.country | Import from Salesforce | Configurable |
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
| Salesforce Field | WeGive Field | WeGive API Field | Direction | Type | Notes |
|---|---|---|---|---|---|
| Id | Salesforce ID | salesforce_id | Import from Salesforce | Hard-coded | Salesforce’s unique identifier for this household account |
| Name | Household Name | name | Both Ways | Configurable import, Hard-coded export | |
| RecordTypeId | Record Type | Dynamic | Import from Salesforce | Hard-coded | Queried from RecordType based on household_record_type_name setting |
| npe01__One2OneContact__c | Primary Contact Salesforce ID | salesforce_contact_id | Both Ways | Configurable import, Hard-coded export | Links to primary household member |
| primaryContactColumn | Primary Contact Salesforce ID | salesforce_contact_id | Import from Salesforce | Hard-coded | Configurable field name; maps to primary household member |
| wegive__WeGive_Id__c | WeGive Household ID | id | Export to Salesforce | Hard-coded | WeGive’s unique identifier for this household |
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_namesetting (default: “Organization”) - The
Typefield is automatically set to “Organization” For Households: - Record Type is determined by the
household_record_type_namesetting (default: “Household Account”) - The
Typefield is not set (households typically do not have a Type value)
Primary Contact Linking
For Companies: Thenpe01__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).
Related Documentation
- Data Mapping Overview - object index and cross-cutting data conventions
- Configuring Salesforce State and Country Picklist Mappings - customer setup walkthrough in the Knowledge Base