The MoveData donation pipeline (MoveDataDonationPipeline) is a multi-stage processing engine that transforms donation notifications from fundraising platforms into structured Salesforce records. It implements the donation schema and supports complex fundraising scenarios including peer-to-peer campaigns, recurring donations, matched gifts, and tribute donations.

The pipeline processes each notification through a series of sequential stages. Each stage handles a specific aspect of the donation workflow, creating or updating Salesforce records while maintaining relationships between donors, campaigns, and donations.

Implementations#

The donation pipeline is implemented through MoveData extensions that provide out-of-the-box processing flows for different Salesforce data models. Each extension registers its processing handlers with the pipeline through metadata configuration, providing turnkey functionality while allowing customisation through Lightning Flows and business rules.

For an overview of how extensions work with pipelines, see Understanding extensions.

Execution modes#

The donation pipeline supports two execution modes.

Multi-step processing (default)#

Multi-step processing runs notifications through discrete, sequential stages with full relationship management and business rule support. This is the default mode and is suitable for the vast majority of implementations.

The remainder of this article covers multi-step processing in detail.

Single-step processing (alternative)#

Single-step processing provides a streamlined approach where all business logic is handled within a single flow or Apex handler. This mode is appropriate in rare cases, such as when an organisation writes to a Salesforce staging object rather than directly to standard records.

For details on configuring and using single-step mode, see Single-step pipeline mode.

Multi-step pipeline stages#

The multi-step pipeline processes notifications through seven stages, executed in order:

Stage 0: Configuration#

Purpose: Set Config_ values that are conditional or that represent advanced configuration settings not exposed in the settings interface.

Metadata key: PIPELINE_DONATION_CONFIGURATION

This stage does not create any Salesforce records. It runs before all other stages, allowing you to control the behaviour of subsequent stages based on notification data.

Stage 1: Pre-processing (optional)#

Purpose: Transform or enhance the notification payload before the main processing stages begin.

Metadata key: PIPELINE_DONATION_PREPROCESS

Use this stage when you need to modify the notification data itself, such as transforming specific information in the payload before processing.

This stage does not create any Salesforce records directly.

Stage 2: Account processing#

Purpose: Create or update Account records for organisational donors, fundraising organisations, and matched gift companies.

Default SObject:

• NPSP: Account
• Nonprofit Cloud: Account

The account stage processes several types of account record:

• Campaign-related accounts (fundraising organisations)
• Donor accounts (organisational donors)
• Matched gift company accounts
• Tribute organisation accounts

The pipeline calls the account stage once for each account present in the notification — for example, a notification may contain both a donor account and a fundraising organisation account, resulting in the account stage running multiple times. Use the context variables to determine which type of account is being processed.

Stage 3: Contact processing#

Purpose: Create or update Contact records for individual donors, fundraisers, and tribute contacts.

Default SObject:

• NPSP: Contact
• Nonprofit Cloud (Person Accounts): Account

The contact stage processes several types of contact record:

• Individual fundraisers and team captains
• Matched gift contact persons
• Tribute and memorial contacts
• One-off and recurring donors

The pipeline calls the contact stage once for each contact present in the notification — for example, a notification may contain both a fundraiser and a donor, resulting in the contact stage running multiple times. For Nonprofit Cloud, contacts are processed as Person Accounts. Use the context variables to determine which type of contact is being processed.

Stage 4: Campaign processing#

Purpose: Create or update Campaign records representing fundraising initiatives and peer-to-peer hierarchies.

Default SObject: Campaign

The campaign stage manages hierarchical campaign relationships, including parent-child linking for multi-level peer-to-peer campaign structures. The pipeline calls the campaign stage once for each campaign in the hierarchy. Use the context variables to determine the campaign's position and relationships.

Stage 5: Recurring donation processing#

Purpose: Create or update recurring donation records for subscription-based giving.

Default SObject:

• NPSP: npe03__Recurring_Donation__c
• Nonprofit Cloud: GiftCommitment

This stage only runs when the notification contains a recurring donation. For one-off donations, the pipeline skips this stage entirely.

Stage 6: Donation processing#

Purpose: Create or update individual donation records.

Default SObject:

• NPSP: Opportunity
• Nonprofit Cloud: GiftTransaction

The donation stage creates the final record and establishes relationships to all previously processed records:

• Links to the donor contact and account
• Associates with the relevant campaign
• Connects to the recurring donation record (if applicable)
• Handles matched gift relationships

Context variables#

Each stage receives context variables that indicate what type of record is being processed in the current iteration. These variables are essential when you build custom flows that need to apply different logic depending on the record type.

Account stage context#

Contact stage context#

Campaign stage context#

Other resources#

• Pipeline overview — how pipelines and metadata keys work
• Commerce pipeline — the equivalent pipeline for commerce and ticketing data
• Single-step pipeline mode — alternative execution mode for specialised use cases
• Understanding extensions — how extensions implement pipeline processing