> ## Documentation Index > Fetch the complete documentation index at: https://docs.wegive.com/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** - 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](#household-salesforce-id-origin). ## Company 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. Written on import and after a successful insert. | | Name | Company Name | `name` | Both Ways | Configurable import, Hard-coded export | | | Type | Organization Type | `'Organization'` default, or a per-subtype configured value | Export to Salesforce | Hard-coded default, configurable override | See [Account Type and Company Subtypes](#account-type-and-company-subtypes) below. | | RecordTypeId | Record Type | Dynamic | Export to Salesforce | Hard-coded | Sent on create only. Looked up by the `non_household_record_type_name` setting (default `Organization`). If no record type with that name exists, null is sent and Salesforce applies its default. | | npe01\_\_One2OneContact\_\_c (or the column named by `primary_contact_column`) | Primary Contact Salesforce ID | `salesforce_contact_id` | Export to Salesforce | Configurable (mapping rule) | No built-in default. On export the value offered to rules is the `salesforce_id` of the primary individual, see [Primary Contact Linking](#primary-contact-linking). Sent on both create and update when a rule maps it. | | npe01\_\_One2OneContact\_\_c (or the column named by `primary_contact_column`) | Primary Donor | `primary_donor_id` | Import from Salesforce | Hard-coded | Resolved to the WeGive individual donor with that `salesforce_id`, used for [email inheritance](#email-inheritance-from-primary-contact-companies-only), and then discarded. Not stored on the company. | | Phone | Office Phone | `office_phone` | Both Ways | Configurable import, Hard-coded export | | | Fax | Fax | `fax` | Both Ways | Configurable import, Hard-coded export | | | wegive\_\_WeGive\_Id\_\_c | WeGive Donor ID | `id` | Export to Salesforce | Hard-coded | Requires the WeGive managed package. Dropped automatically if the org's package lacks the field, and dropped for multi-entity Salesforce orgs where Account is shared across WeGive organizations. | | 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. | 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): | 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 Households are import only. Every field below flows from Salesforce into WeGive; nothing is written back to the Household Account. | 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` | Import from Salesforce | Hard-coded | | | RecordTypeId | Record Type | Not stored | Import from Salesforce | Hard-coded | Used only as the pull filter, matched against the `household_record_type_name` setting (default `Household Account`) | | npe01\_\_One2OneContact\_\_c (or the column named by `primary_contact_column`) | Primary Contact Salesforce ID | `salesforce_contact_id` | Import from Salesforce | Hard-coded | Identifies the primary household member. The column name is configurable through `primary_contact_column`; the mapping itself is fixed. | 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](#email-inheritance-from-primary-contact-companies-only), 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](#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](#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 | Setting | Effect | | :- | :- | | Pull companies (Sync Configuration) | Enables pulling non-household Accounts as company donors | | Pull households (Sync Configuration) | Enables pulling Household Accounts as WeGive households | | Push donors (Sync Configuration) | Enables pushing company donors to Accounts (households are never pushed) | | `pull_by` | Salesforce column used for the sync window. Default `LastModifiedDate`. | | `household_record_type_name` | Record type name that identifies Household Accounts. Default `Household Account`. | | `non_household_record_type_name` | Record type name stamped on new company Accounts and used for the deleted-companies pull. Default `Organization`. | | `primary_contact_column` | Account column holding the primary Contact ID. Default `npe01__One2OneContact__c`. | | `pull_deleted_households` | Enables deleting WeGive households when their Household Account is deleted in Salesforce | | `pull_deleted_companies` | Enables deleting WeGive company donors when their Account is deleted in Salesforce | ## Related Documentation * [Data Mapping Overview](./overview) - object index and cross-cutting data conventions * [Contact](./contact) - individual donor mapping * [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 *Verified against the integration source, September 2026.* This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.