> ## 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. # Integration Nuances > Behaviors, limits, and design decisions to know about in the WeGive Salesforce Nonprofit Cloud integration ## 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](/external/onboarding/npc/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](/external/onboarding/npc/setup-requirements#first-sync-order)), 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](/external/onboarding/npc/data-mapping/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](/salesforce-npsp/introduction). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.