Skip to main content

​
Person Accounts are required

NPC’s supporter model depends on Salesforce Person Accounts: Account records with an embedded Contact. WeGive discovers your Person Account record type ID at connect time and stores it.
  • Person Accounts must be enabled before you connect WeGive. If you enable them afterward, re-run the authorization so WeGive can re-discover record types.
  • WeGive recognizes three Account record types: Person Account (individuals), Organization (companies), and optionally Household. Other record types are pulled as companies unless you list them under Hidden record types.
  • CampaignMember references the embedded Contact, not the Account. WeGive resolves PersonContactId when pushing campaign members and maps Contact IDs back to Accounts on pull.

​
Record types are set on create only

WeGive stamps the configured record type when it creates an Account. It never changes the record type on update, so record types assigned in Salesforce are preserved.

​
Polling-based pull, no inbound webhooks

NPC does not push change events to WeGive. Changes flow in through a scheduled pull that queries LastModifiedDate for records changed since the last run.
  • The pull interval defaults to 15 minutes. See Configuration Options.
  • Deletions are detected by querying records where IsDeleted = true. Expect a deletion to reach WeGive within one pull interval.
  • Merges are detected the same way: WeGive reads merged Accounts with a MasterRecordId and merges the corresponding WeGive records so linkage stays correct.

​
Duplicate rules

When WeGive creates an Account it bypasses Salesforce duplicate rules so the push does not fail. Your org’s duplicate management remains the source of truth: when you merge duplicates in Salesforce, the merge flows back to WeGive on the next pull.

​
Schema-aware queries

NPC orgs on different releases expose different fields. Before each pull, WeGive checks which fields and child relationships your org exposes and only queries those that exist. This matters for:
  • Gateway fields on GiftTransaction and GiftRefund (GatewayReference, GatewayTransactionFee, DonorCoverAmount), which require API version 60.0 or later. On older versions these are omitted from both pulls and pushes.
  • Designation relationships (GiftTransactionDesignationRelation, GiftDefaultDesignationParentRecords). If the relationship is not exposed, designation sync is skipped rather than failing the whole pull.
The schema check is cached for 24 hours per connection.

​
Bulk API 2.0 is scoped to CampaignMember pushes only

Bulk API 2.0 is real in this integration, but it is not used for general historical imports or large back-fills as previously stated here. createBulkJob()/checkBulkJobStatus() (the only Bulk API 2.0 code in Npc.php) are called exclusively from the queued CampaignMember batch push job. Every pull — including the very first historical sync after you connect, for every object (donors, transactions, recurring plans, etc.) — runs through the plain REST /query endpoint with nextRecordsUrl pagination, not Bulk API 2.0. A large org’s initial sync can still take a while (see Setup Requirements), it’s just paginated REST rather than a bulk job underneath.

​
Designations and fund allocations

How designations sync depends on the Fund allocations setting:
  • On: each GiftTransactionDesignationRelation row becomes a fund allocation on the WeGive transaction, and each GiftDefaultDesignation on a GiftCommitment becomes a fund allocation on the recurring plan. On push, WeGive writes its allocation rows and removes designations it does not track so totals stay at 100 percent.
  • Off: the largest designation maps to the transaction’s single fund. On push, WeGive writes one 100 percent designation and adopts an existing designation if NPC already created one, so it never deletes designations it did not create.
GiftDefaultDesignation is percentage-based. WeGive converts allocation amounts to percentages on push and back to amounts on pull using the plan amount.

​
Recurring plans without a schedule

Salesforce allows a GiftCommitment with no GiftCommitmentSchedule. When a schedule is missing, WeGive falls back to the commitment-level NextTransactionAmount, EffectiveTransactionPeriod, and EffectiveTransactionInterval to determine the plan amount and frequency. If no amount can be resolved, the record is skipped rather than imported incomplete.

​
WeGive-processed gifts keep WeGive-owned fields

For transactions charged through WeGive, the amount, status, date, payment method, and fees are owned by WeGive. Edits to those fields in Salesforce are not pulled back. This protects scheduled and future-dated charges from being altered by CRM-side edits.

​
Soft credits are split records

GiftSoftCredit records are pulled separately from their parent GiftTransaction. Each row is its own soft credit with a PartialAmount. See Soft Credit.

​
Login provisioning

When a Person Account has an AccountContactRelation whose role is in Login contact roles, WeGive creates a login for that supporter on the related company. WeGive fetches these relations in batches during the supporter pull; a failure in this step is logged and does not stop the supporter import.

​
Currency

WeGive stores amounts in cents. Amounts are divided by 100 before pushing to NPC currency fields and multiplied back on pull.

​
Rate limiting

Standard Salesforce REST limits apply. WeGive retries transient failures with backoff and respects Salesforce limit headers.

​
What WeGive does not do

  • No managed package. NPC sync uses standard objects only.
  • No field creation. WeGive does not create custom fields on NPC objects. Create the field in Salesforce first, then map to it.
  • No NPSP Opportunity reading. The NPC integration is wired to GiftTransaction. If you need NPSP-era Opportunities synced, use the NPSP integration.