> ## Documentation Index > Fetch the complete documentation index at: https://wegive.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Account > 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 | 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](#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](#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](#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](#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_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): | 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 | 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](https://wegive-help-center.help.usepylon.com/articles/3843908042-configuring-salesforce-state-and-country-picklist-mappings-in-wegive) 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_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). ## Related Documentation * [Data Mapping Overview](./overview) - object index and cross-cutting data conventions * [Configuring Salesforce State and Country Picklist Mappings](https://wegive-help-center.help.usepylon.com/articles/3843908042-configuring-salesforce-state-and-country-picklist-mappings-in-wegive) - customer setup walkthrough in the Knowledge Base