Skip to main content
How WeGive objects map to Salesforce NPSP objects, and the conventions that govern every field mapping
This page is the index for the WeGive Salesforce NPSP field mapping reference. It lists every object pair the integration syncs, links to the field-by-field detail for each, and documents the conventions (amount units, dates, picklists, sync direction) that apply across all of them. The mappings and sync behavior on these pages are written from the integration’s actual behavior rather than from the dashboard, so where a screen and a page disagree, the page is the reference. This is reference material. To learn how to add or change a mapping in your own account, see Add or edit a field mapping in the Knowledge Base. (Editor note: link to the V2 Pylon article once published.)

​
How mapping works

WeGive syncs in two directions. It pulls records from Salesforce (querying by last modified date) to create or update the matching WeGive record, and it pushes changes from WeGive by compiling a payload for the Salesforce object. Each object is synced as a pair: one WeGive model to one Salesforce object. For a customer-facing explanation of how the sync runs (sync toggles, what Sync All does, and scheduled timing), see How the Salesforce Sync Works in the Knowledge Base. Every field mapping has a direction and a type. Direction describes which way the data flows:
  • Import from Salesforce - data flows from Salesforce into WeGive only.
  • Export to Salesforce - data flows from WeGive into Salesforce only.
  • Both Ways - data syncs in both directions.
Type describes whether the mapping can be changed:
  • Configurable - mapped through integration settings; you can repoint or remove it.
  • Hard-coded - built into the integration logic to handle a business rule (email selection, name defaults, amount conversion) and cannot be changed.
When you add a custom mapping rule, you enter a WeGive API name (for example ends_at or mailing_address.city) on the WeGive side and the Salesforce field on the other. The per-object pages below list the valid WeGive API names for each object.

​
Object index

​
Donor management

​
Donation management

The NPSP Payment object is only written when the uses_payments setting is enabled. See Configuration Options for what that setting does.

​
Funds and gift detail (NPSP)

The GAU object API name can be overridden per org with the fund_api_name setting for orgs whose schema differs from NPSP defaults.

​
WeGive managed package objects

These objects exist only after the WeGive managed package is installed. Their fields carry the wegive__ namespace prefix. The four event objects and the Tag object are push-only (WeGive to Salesforce); Tag Donor assignments sync in both directions. Every other object in this index syncs in both directions unless its detail page says otherwise. A small number of orgs use non-namespaced or alternately named fields for the Pledge and Payout objects (legacy custom builds). Those overrides are configured per integration; contact WeGive to confirm an org’s object names.

​
Campaign

​
Data handling conventions

These rules apply to every mapping. They are the most common source of “the value came across wrong” questions. Amounts. WeGive stores money in cents; Salesforce stores dollars. The default mappings divide by 100 on push and multiply by 100 on pull. If you map the raw amount field directly to a Salesforce currency field you will get cents, which is almost always wrong. Use the computed dollar_amount value or rely on the default mapping. Dates. WeGive stores *_at columns as UTC datetimes and *_date columns as dates. The integration formats dates as YYYY-MM-DD for Salesforce and adjusts close dates and campaign dates to the org timezone. Booleans. Salesforce checkbox fields accept WeGive booleans directly; no conversion is needed. Picklists. Salesforce picklist fields silently reject a value that is not in the allowed set, so a mapped value can disappear with no error. Align the values WeGive sends with the org’s picklist. This is why donor State and Country are imported from Salesforce but not exported by default. Salesforce State and Country/Territory Picklists is an org-wide setting that applies to both Contact and Account. When it is enabled, state and country on both objects must be mapped through the code fields (for example MailingStateCode, BillingStateCode) using a one-directional export/import split rather than a single both-ways rule. See the Contact and Account pages for the exact mappings. Frequency. WeGive stores frequency as a string (“monthly”, “bimonthly”, “quarterly”, “semiannual”, and so on). For Recurring Donations, the integration translates these into NPSP’s Installment_Period__c + InstallmentFrequency__c pair (NPSP has no native Quarterly/Semiannual/Bimonthly period, so those three cadences are encoded as a multiplier on Monthly or Weekly — see Recurring Donation). For Pledges, frequency is translated to NPSP-style installment strings instead (“1 Payment”, “Monthly”, and so on) — see Pledge.

​
Coming soon

The following are planned but not yet synced:
  • Impact stories (Posts)
  • Impact cards (Impact Numbers)
  • Tasks
  • Notes
  • Files

​
Not currently integrated

These NPSP objects are not synced and are used only for internal Salesforce processes: NPSP Data Import Batch, Deliverable (Grant Deadline), Error, Trigger Handler, Engagement Plan and Engagement Plan Templates, Level, Recurring Donation Change Log, Affiliation (npe5__Affiliation__c), and Relationship (npe4__Relationship__c). Two more items are commonly asked about:
  • Lead. WeGive does not sync Salesforce Leads. Marketing contacts in WeGive are intended for people from systems outside Salesforce; see Lead for the reasoning.
  • NPSP Address (npsp__Address__c). WeGive writes mailing and billing addresses to the standard address fields on Contact and Account, not to NPSP’s Address object. NPSP’s own address management then handles household address propagation.
The WeGive4SF package also installs objects for Journeys, Forms, and Form Submissions. Those objects are present for future use and are not currently populated by the integration.