Skip to main content
Salesforce Object: wegive__Fundraiser__c (custom object)
WeGive Model: CampaignFundraiser

​
Overview

This document describes how peer-to-peer fundraiser data syncs between WeGive and Salesforce. Campaign Fundraisers represent individual fundraising pages created by supporters to raise money on behalf of a campaign. This enables peer-to-peer (P2P) fundraising where supporters create their own fundraising pages, set personal goals, and rally their networks. Note: This feature requires the WeGive managed package to be installed in Salesforce, which includes the custom wegive__Fundraiser__c object.

​
How Campaign Fundraiser Data Syncs

​
Direction

  • Import from Salesforce - Data imports from Salesforce into WeGive only
  • Export to Salesforce - Data exports from WeGive to Salesforce only
  • Both Ways - Data syncs in both directions

​
Mapping Types

  • Hard-coded - Built into the integration logic and cannot be changed

​
Sync Triggers

​
From WeGive to Salesforce (Export)

Campaign Fundraiser data is exported from WeGive to Salesforce when:
  • Fundraiser Created: A new fundraising page is created in WeGive
  • Fundraiser Updated: An existing fundraising page is modified in WeGive (e.g., name changed, description updated, dates modified, settings changed)
The export happens automatically after the create or update action in WeGive.

​
From Salesforce to WeGive (Import)

Campaign Fundraiser data is imported from Salesforce to WeGive based on:
  • Last Modified Date: WeGive periodically polls Salesforce for Fundraisers that have been modified since the last sync
  • Sync Frequency: The integration checks for updated Fundraisers on a scheduled basis (frequency varies by integration configuration)
  • Modified Field Tracking: Only Fundraisers with a LastModifiedDate newer than the last successful sync are pulled into WeGive
This means:
  • Creating a new Fundraiser in Salesforce will import it to WeGive on the next sync cycle
  • Updating an existing Fundraiser in Salesforce will trigger an import to WeGive on the next sync cycle
  • The sync is based on Salesforce’s LastModifiedDate field, not individual field changes

​
Sync Process Overview

​
Fundraiser-Level Synchronization

WeGive syncs campaign fundraisers at the Fundraiser object level in Salesforce, maintaining peer-to-peer fundraising page information, settings, dates, and visibility preferences.

​
Pulling Data from Salesforce

When pulling data from Salesforce, WeGive queries Fundraiser records based on the last modified date and any specific filtering criteria. The integration pulls comprehensive data from the Fundraiser record, including all standard and custom fields that have been mapped. The import process includes:
  • Fundraiser Identification: Creates or updates the corresponding WeGive CampaignFundraiser record
  • Settings Import: Maintains all fundraiser settings and preferences
  • Date Tracking: Imports start and end dates for the fundraising campaign
  • Visibility Settings: Preserves display preferences for activity, leaderboards, and child fundraisers
  • WeGive ID Mapping: Stores the WeGive fundraiser ID for reference

​
Pushing Data to Salesforce

When a CampaignFundraiser is created or updated in WeGive, the integration compiles a payload for the Salesforce Fundraiser object. This payload includes all mapped fields and ensures that the Fundraiser record is properly created or updated in Salesforce. The integration handles:
  • Standard Fields: Name, description, dates, slug
  • Boolean Settings: Allow fundraising, hide fundraise button, show activity, etc.
  • WeGive Reference Fields: WeGive ID for cross-reference
  • Date Formatting: Properly formats dates to Y-m-d format

​
Standard Field Mappings

Salesforce FieldWeGive FieldWeGive API FieldDirectionTypeNotes
IdSalesforce IDsalesforce_idImport from SalesforceHard-codedSalesforce’s unique identifier for this fundraiser
NameFundraiser NamenameBoth WaysHard-codedDisplay name of the fundraising page
wegive__WeGive_Id__cWeGive Fundraiser IDidExport to SalesforceHard-codedWeGive’s unique identifier for cross-reference
wegive__Description__cDescriptiondescriptionBoth WaysHard-codedDetailed description of the fundraising page
wegive__Slug__cURL SlugslugBoth WaysHard-codedURL-friendly identifier for the fundraising page
wegive__Start_Date__cStart Datestart_dateBoth WaysHard-codedDate the fundraising campaign begins
wegive__End_Date__cEnd Dateend_dateBoth WaysHard-codedDate the fundraising campaign ends
wegive__Allow_Fundraising__cAllow Fundraisingallow_fundraisingBoth WaysHard-codedWhether supporters can create sub-fundraisers
wegive__Hide_Fundraise__cHide Fundraise Buttonhide_fundraiseBoth WaysHard-codedWhether to hide the “Start Fundraiser” button
wegive__Show_Activity__cShow Activityshow_activityBoth WaysHard-codedWhether to display donation activity on the page
wegive__Show_Leader_Board__cShow Leader Boardshow_leader_boardBoth WaysHard-codedWhether to display the fundraiser leaderboard
wegive__Show_Child_Fundrasiers__cShow Child Fundraisersshow_child_fundraisersBoth WaysHard-codedWhether to display sub-fundraisers
wegive__Donations_p2p_Only__cP2P Donations Onlydonations_p2p_onlyBoth WaysHard-codedWhether donations must be attributed to a fundraiser
wegive__Donate_After_Expiration__cAllow Donations After Expirationdonate_after_expirationBoth WaysHard-codedWhether donations are accepted after end date

​
Note: Additional fields can be mapped through integration rules. The fields shown above represent the standard NPSP GAU fields that are commonly mapped.

​
Important Notes

​
Custom Fund Objects

Some organizations use custom fund objects instead of the standard NPSP GAU object. The integration supports this through the fund_api_name setting. If your organization uses a custom fund object:
  • The object API name is configured in the integration settings
  • Field mappings may differ from the standard NPSP implementation
  • Contact WeGive support for specific field mapping documentation

​
Active Status Handling

The active field is converted to a boolean value during import:
  • If the value can be validated as a boolean, it’s set to true or false
  • This ensures consistent active/inactive status across both systems
  • Inactive funds typically cannot be selected for new donations but remain for historical reporting

​
Fund Allocations

Funds work in conjunction with the Allocation object:
  • Transactions can have allocations to one or more funds
  • Recurring Donations can have allocations to one or more funds
  • Allocations specify either a fixed amount or percentage going to each fund
  • See the Allocation documentation for details on how donations are allocated to funds

​
Integration with Donations

When a transaction or recurring donation has a fund assigned:
  • The fund_id field on the transaction/recurring donation links to the WeGive fund
  • In Salesforce, this is represented through Allocation records
  • If fund allocations are NOT enabled, a single allocation is created linking the Opportunity to the GAU
  • If fund allocations ARE enabled, multiple allocations can exist per Opportunity/Recurring Donation

​
Fund Matching & Create/Update Logic

​
When WeGive Exports a Fund to Salesforce

The integration uses the following logic to determine whether to create a new GAU or update an existing one: Step 1: Check for Existing Salesforce Fund ID
  • If the WeGive fund has a salesforce_id: The integration UPDATES the existing GAU record in Salesforce
  • If no salesforce_id exists: The integration CREATES a new GAU record in Salesforce
Note: Unlike donors, funds are NOT matched by name or other criteria. Each WeGive fund maps to exactly one Salesforce GAU record based solely on the stored Salesforce ID.

​
When Salesforce Exports a Fund to WeGive

Step 1: Check for Existing WeGive Fund
  • The integration searches for an existing fund by salesforce_id
  • If found, it updates that fund
  • If not found, it creates a new fund
Step 2: Import Data
  • All mapped fields are imported from the GAU record
  • Boolean values (like active status) are properly converted
  • Custom field values are processed through the custom fields system

​
Why This Matters

This matching logic ensures:
  • Each WeGive fund maps to exactly one Salesforce GAU record
  • Fund definitions remain consistent across both systems
  • Historical allocations continue to reference the correct fund
  • No duplicate funds are created during sync operations

​
Integration Rules

Organizations can create custom mapping rules for funds to handle:
  • Additional custom fields on the GAU object
  • Organization-specific fund tracking fields
  • Custom reporting or categorization fields
These rules are configured in the neon_mapping_rules table with:
  • crm = ‘salesforce’
  • integration = ‘fund’
  • level = ‘import’, ‘export’, or ‘both’

​
Example Configurable Mappings

The integration supports both configurable import and hard-coded behavior. Common configurable fields include:
  • Custom categorization fields
  • Fund hierarchy relationships
  • Budget or goal tracking fields
  • Program codes or cost centers

​
Required Fields

For WeGive to Salesforce:
  • Name (required by Salesforce)
For Salesforce to WeGive:
  • Id (Salesforce ID - automatically provided)
  • Name (required field)
All other fields are optional and will sync according to the mapping rules configured for your organization.

​
Usage in WeGive

Funds in WeGive are used for:
  • Designating Donations: Donors can select which fund(s) their donation supports
  • Reporting: Generate reports showing donations by fund/designation
  • Campaigns: Campaigns can be tied to specific funds
  • Allocations: Split a single donation across multiple funds (when fund allocations are enabled)
  • Recurring Donations: Set default fund designations for ongoing giving

​
Usage in Salesforce NPSP

General Accounting Units in Salesforce are used for:
  • Allocation Tracking: Track which portion of donations go to which programs/funds
  • Reporting: Run reports on donations by GAU
  • Campaign GAUs: Associate campaigns with specific GAUs
  • Rollup Summaries: NPSP can roll up donation totals to GAUs
  • Budget Tracking: Compare actual donations vs. budgeted amounts

​
Understanding Configurable vs Hard-coded

  • Configurable mappings can be customized through integration settings if needed for your organization’s specific field setup
  • Hard-coded mappings are built into the integration’s core logic and handle essential fund identification and tracking
  • The Name field is configurable on import to allow organizations to map from custom field names
  • The Name field is hard-coded on export to ensure the required Salesforce field is always populated

​
Best Practices

  1. Keep fund names consistent between systems to avoid confusion
  2. Set active status appropriately - inactive funds should not be available for new donations
  3. Use fund allocations when donations need to be split across multiple programs
  4. Document fund purposes in the description field for clarity
  5. Review fund lists regularly to retire unused funds and add new ones as needed
  6. Coordinate fund creation between systems - create in one system and let it sync rather than creating duplicates
  7. Test fund mappings when setting up the integration to ensure allocations work correctly

​
Troubleshooting

Fund not syncing:
  • Verify the fund has been modified since the last sync time
  • Check that the integration is not configured to use a custom fund object name
  • Ensure the fund has a valid name in both systems
Allocations not working:
  • Verify funds have Salesforce IDs before creating transactions with allocations
  • Check that fund allocations are enabled in the organization settings
  • Ensure the GAU exists in Salesforce and is active
Duplicate funds:
  • Funds are only matched by Salesforce ID, so creating a fund with the same name in both systems will result in duplicates
  • Merge duplicate funds in the system of record, then sync