> ## Documentation Index
> Fetch the complete documentation index at: https://wegive.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Fundraiser

> Mapping between WeGive Campaign Fundraisers and Salesforce Campaign Fundraisers

**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 Field                         | WeGive Field                     | WeGive API Field          | Direction              | Type       | Notes                                                |
| :--------------------------------------- | :------------------------------- | :------------------------ | :--------------------- | :--------- | :--------------------------------------------------- |
| Id                                       | Salesforce ID                    | salesforce\_id            | Import from Salesforce | Hard-coded | Salesforce's unique identifier for this fundraiser   |
| Name                                     | Fundraiser Name                  | name                      | Both Ways              | Hard-coded | Display name of the fundraising page                 |
| wegive\_\_WeGive\_Id\_\_c                | WeGive Fundraiser ID             | id                        | Export to Salesforce   | Hard-coded | WeGive's unique identifier for cross-reference       |
| wegive\_\_Description\_\_c               | Description                      | description               | Both Ways              | Hard-coded | Detailed description of the fundraising page         |
| wegive\_\_Slug\_\_c                      | URL Slug                         | slug                      | Both Ways              | Hard-coded | URL-friendly identifier for the fundraising page     |
| wegive\_\_Start\_Date\_\_c               | Start Date                       | start\_date               | Both Ways              | Hard-coded | Date the fundraising campaign begins                 |
| wegive\_\_End\_Date\_\_c                 | End Date                         | end\_date                 | Both Ways              | Hard-coded | Date the fundraising campaign ends                   |
| wegive\_\_Allow\_Fundraising\_\_c        | Allow Fundraising                | allow\_fundraising        | Both Ways              | Hard-coded | Whether supporters can create sub-fundraisers        |
| wegive\_\_Hide\_Fundraise\_\_c           | Hide Fundraise Button            | hide\_fundraise           | Both Ways              | Hard-coded | Whether to hide the "Start Fundraiser" button        |
| wegive\_\_Show\_Activity\_\_c            | Show Activity                    | show\_activity            | Both Ways              | Hard-coded | Whether to display donation activity on the page     |
| wegive\_\_Show\_Leader\_Board\_\_c       | Show Leader Board                | show\_leader\_board       | Both Ways              | Hard-coded | Whether to display the fundraiser leaderboard        |
| wegive\_\_Show\_Child\_Fundrasiers\_\_c  | Show Child Fundraisers           | show\_child\_fundraisers  | Both Ways              | Hard-coded | Whether to display sub-fundraisers                   |
| wegive\_\_Donations\_p2p\_Only\_\_c      | P2P Donations Only               | donations\_p2p\_only      | Both Ways              | Hard-coded | Whether donations must be attributed to a fundraiser |
| wegive\_\_Donate\_After\_Expiration\_\_c | Allow Donations After Expiration | donate\_after\_expiration | Both Ways              | Hard-coded | Whether 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
