> ## 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.

# Setup Requirements

> Org, licensing, and user requirements for the WeGive Salesforce Nonprofit Cloud integration

Your Salesforce org must meet the requirements below before you connect it to WeGive. Authorization and connection are covered on [External Client App and Connection Setup](/external/onboarding/npc/install-setup/external-client-app).

<Info>
  Implementing for the first time? The [Sandbox-First Implementation Guide](/external/onboarding/npc/install-setup/implementation-guide) sequences every step from Sandbox through Production go-live, with a checkpoint at the end of each phase.
</Info>

<Note>
  NPC is a paid Salesforce product. If your org runs the free NPSP package, use the [Salesforce NPSP integration](/salesforce-npsp/setup-requirements) instead.
</Note>

## Salesforce org

| Requirement | Detail |
| - | - |
| Nonprofit Cloud | Enabled and configured on the org (production or sandbox). |
| Person Accounts | Enabled. NPC individual supporters are Person Accounts. WeGive discovers your Person Account record type ID at connect time; without Person Accounts, supporter sync cannot run. |
| Account record types | A Person Account record type and an Organization record type. A Household record type is optional; if none exists, household sync is disabled. |
| API version | Salesforce REST API 59.0 or later. WeGive defaults to 59.0 and lets you select a newer version your org supports. Some gateway fields on `GiftTransaction` and `GiftRefund` require 60.0 or later. |

## No managed package

NPC does not require a WeGive managed package. All sync uses standard NPC objects through the REST API (plus Bulk API 2.0 for `CampaignMember` batch pushes specifically — see [First sync order](#first-sync-order) below). WeGive does not create custom fields on NPC objects; if you want a custom field synced, your Salesforce admin creates it first and it is then added to your mapping rules.

## Integration user

Connect WeGive with a dedicated integration user rather than a personal admin login. The user needs:

* The **Fundraising Access** permission set license
* The **Fundraising User** permission set
* Read and write access to `Account`, `Contact`, `Campaign`, `CampaignMember`, `GiftTransaction`, `GiftTransactionDesignation`, `GiftCommitment`, `GiftCommitmentSchedule`, `GiftDefaultDesignation`, `GiftDesignation`, `GiftSoftCredit`, `GiftRefund`, and `GiftTribute`
* API Enabled
* Permission to use Bulk API 2.0 (used for `CampaignMember` batch push operations, not general historical imports — see [First sync order](#first-sync-order) below)

A System Administrator is needed once, to create the External Client App and authorize the connection.

## What WeGive discovers at connect time

After you authorize, WeGive reads your org and stores:

* Person Account, Organization, and Household record type IDs
* The API versions your org supports
* Which optional `GiftTransaction` fields and child relationships your schema exposes
* Available `GiftType`, `PaymentMethod`, and `Status` picklist values, used to seed the pull filters
* Available `AccountContactRelation` roles, used for login provisioning

Record type IDs and filters can be adjusted afterward under [Configuration Options](/external/onboarding/npc/configuration-options).

## Environments

WeGive **Test** dashboards connect to Salesforce **Sandbox** orgs and WeGive **Live** dashboards connect to **Production**. Tokens are stored per connection, so switching orgs means re-running the authorization. Settings and mappings do not carry over between Test and Live.

## First sync order

After you enable the integration, WeGive pulls objects in this order:

1. Households
2. Person Accounts (individual supporters) and Organization Accounts (companies)
3. Campaigns
4. `GiftDesignation` records (funds)
5. `GiftCommitment` records and their schedules (recurring plans)
6. Pledges (also `GiftCommitment`, formal commitment type)
7. `GiftTransaction` records
8. `GiftRefund` records
9. Campaign supporters (`CampaignMember`)
10. Soft credits

<Note>
  This is the actual pull order WeGive runs, not a logical/dependency grouping — recurring plans and pledges are pulled *before* transactions, for example, not after. Every pulled object still links correctly regardless of order (a transaction referencing a not-yet-pulled recurring plan is resolved on a later pass), so this only matters if you're watching sync progress and expect a different sequence.
</Note>

Large orgs import through **REST queries with pagination** (`nextRecordsUrl`), not Bulk API 2.0 — see the note below. Expect minutes to hours for orgs with hundreds of thousands of transactions; progress appears in the integration log in the dashboard.

<Warning>
  **Bulk API 2.0 is real, but scoped narrower than "historical imports" implies.** WeGive's NPC integration only uses Bulk API 2.0 for `CampaignMember` batch push operations (`createBulkJob()`/`checkBulkJobStatus()`, used by the queued campaign-member sync job). Every other object — donors, companies, households, transactions, recurring plans, pledges, soft credits, refunds, including the very first historical pull after you connect — goes through plain per-page REST SOQL queries (`services/data/{version}/query`, paginated via `nextRecordsUrl`), not Bulk API 2.0.
</Warning>

## Next steps

1. [Sandbox-First Implementation Guide](/external/onboarding/npc/install-setup/implementation-guide) for the full sequence, or go directly to:
2. [External Client App and Connection Setup](/external/onboarding/npc/install-setup/external-client-app)
3. [Configuration Options](/external/onboarding/npc/configuration-options)
4. [Data Mapping Overview](/external/onboarding/npc/data-mapping/overview)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.