> ## 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 > Salesforce edition, package, NPSP configuration, and user requirements for the WeGive Salesforce NPSP integration Your Salesforce org must meet the requirements below before you install the WeGive managed package and connect it to WeGive. Installation is covered on [Installing the WeGive Salesforce Managed Package](/external/onboarding/salesforce-npsp/install-setup/package-install). Authorization and connection are covered on [External Client App and Connection Setup](/external/onboarding/salesforce-npsp/install-setup/connect-app-setup). Implementing for the first time? The [Sandbox-First Implementation Guide](/external/onboarding/salesforce-npsp/install-setup/implementation-guide) sequences every step from Sandbox through Production go-live, with a checkpoint at the end of each phase. ## Salesforce edition The integration supports **Enterprise**, **Unlimited**, and **Developer** Edition orgs. Professional Edition and Essentials are not supported because they do not include API access. ## Required packages | Package | Minimum version | Purpose | | - | - | - | | Nonprofit Success Pack (NPSP) | 3.220 | WeGive reads and writes standard NPSP records: Contacts, Accounts, Opportunities, Payments (`npe01__OppPayment__c`), Recurring Donations (`npe03__Recurring_Donation__c`), GAU Allocations (`npsp__Allocation__c`), General Accounting Units, and Partial and Account Soft Credits. | | WeGive4SF (WeGive managed package) | Current release | Adds WeGive objects (Pledges, Payouts, Events, Communication Lists, Tags, Forms, Journeys) and WeGive fields on standard and NPSP objects. Namespace: `wegive`. | ## NPSP configuration | Setting | Requirement | | - | - | | Account model | Household Account model. | | Enhanced Recurring Donations (RD2) | Recommended. WeGive's Recurring Donation push/pull uses NPSP's standard `npe03__Recurring_Donation__c` fields and doesn't perform an explicit legacy-vs-RD2 version check in code — there's no hard block on a Legacy Recurring Donations org. That said, WeGive's own field-population logic (e.g. the `push_rd_household_for_individuals` toggle, which decides whether an Individual RD also carries the household Account) is designed against RD2's data model; an org still on Legacy RDs should treat this as untested territory rather than confirmed-supported. | | Account record types | One record type for households and one for organizations. WeGive expects `Household Account` and `Organization` by default. Other names can be set in WeGive under **Settings > Integrations > Salesforce NPSP > Sync Configuration > Record Type Configuration**. | | Opportunity record types | Optional. When present, WeGive uses `Donation` for tax-deductible gifts and `Service Revenue` for non-deductible transactions. See [Configuration Options](/external/onboarding/salesforce-npsp/configuration-options#record-type-filtering). | | Accounts as Campaign Members | Optional. Required only to sync company supporters as Campaign Members. | | Middle Name and Name Suffix | Enabled under **Setup > User Interface > Name Settings**. | ## Integration user Connect WeGive with a dedicated integration user rather than a personal admin login, so the connection does not depend on one person's account. The connecting user must have: * System Administrator profile * API Enabled * Modify All Data * View All Data * Customize Application * View Setup and Configuration * The **WeGive Admin** permission set, included in the WeGive4SF package The integration user's username must also be added to the NPSP trigger handler exclusions described on the [connection setup page](/external/onboarding/salesforce-npsp/install-setup/connect-app-setup#npsp-trigger-handler-exclusions). ## Field-level security The integration user must have read and edit access to every field WeGive syncs: * Standard fields on Contact, Account, Opportunity, Payment, Campaign, and Recurring Donation * Fields added by the WeGive4SF package * NPSP fields * Any custom fields you add to your mapping rules Field-level security is granted per profile and permission set in Salesforce. Missing field access is the most common cause of first-sync errors. ## API access * REST API enabled on the org * An **External Client App** authorizing WeGive, configured as described on the [connection setup page](/external/onboarding/salesforce-npsp/install-setup/connect-app-setup) * Sufficient daily API request allocation for your sync volume. WeGive pushes changes within about 5 minutes and pulls from Salesforce every 15 minutes by default; see [Configuration Options](/external/onboarding/salesforce-npsp/configuration-options#sync-timing). ## Environments WeGive **Test** dashboards connect only to Salesforce **Sandbox** orgs. WeGive **Live** dashboards connect only to Salesforce **Production** orgs. A connection attempt across environment types fails. Settings, field mappings, and sync toggles do not transfer between Test and Live. Each dashboard is configured independently. ## Next steps 1. [Sandbox-First Implementation Guide](/external/onboarding/salesforce-npsp/install-setup/implementation-guide) for the full sequence, or go directly to: 2. [Installing the WeGive Salesforce Managed Package](/external/onboarding/salesforce-npsp/install-setup/package-install) 3. [External Client App and Connection Setup](/external/onboarding/salesforce-npsp/install-setup/connect-app-setup) 4. [Data Mapping Overview](/external/onboarding/salesforce-npsp/data-mapping/overview) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.