Your data in Nonprofit Cloud
When MoveData processes data from your fundraising platform into Salesforce with Nonprofit Cloud, it creates and updates specific records. This article covers what those records are, the key fields MoveData sets, and how it finds existing records to avoid duplicates.
Using NPSP instead?
This article covers the Nonprofit Cloud data model. If your org uses NPSP, see Your data in NPSP.
Person Accounts#
In Nonprofit Cloud, individual supporters are stored as Person Accounts — a Salesforce record type that combines an Account and Contact into one. MoveData creates or updates a Person Account for each donor, fundraiser, or team captain.
Key fields set by MoveData#
| Field | Description |
|---|---|
| First Name, Last Name | Supporter's name from the platform |
| Person Email | Primary email address |
| Phone | Phone number if provided |
| Person Mailing Address | Street, City, State, Country, Postal Code |
| Record Type | Set according to extension configuration |
How MoveData finds existing person accounts#
MoveData uses a two-stage matching process:
- Platform key — checks for a unique ID assigned by your fundraising platform
- Salesforce Duplicate Rules — if no platform key match is found
For more on configuring duplicate rules, see Duplicate rules.
Accounts (Organisations)#
For organisational donors (e.g. a company making a corporate donation), MoveData creates or updates a separate Organisation Account.
MoveData also creates an AccountContactRelation record — a standard Salesforce link — to connect the person account to the organisation account where applicable.
Key fields set by MoveData#
| Field | Description |
|---|---|
| Name | Organisation name |
| Phone | Contact details if provided |
| Billing Address | Street, City, State, Country, Postal Code |
| Record Type | Defaults to Business Account |
How MoveData finds existing accounts#
MoveData uses a two-stage matching process:
- Platform key — checks for a unique ID assigned by your fundraising platform
- Salesforce Duplicate Rules — if no platform key match is found
For more on configuring duplicate rules, see Duplicate rules.
Campaigns#
MoveData creates Salesforce campaigns to represent fundraising activity. Campaign handling is the same for both NPSP and Nonprofit Cloud, since campaigns are standard Salesforce objects.
Campaigns are organised in a hierarchy of up to three levels, linked through the Parent Campaign field.
Campaign hierarchy#
| Level | Description | Example |
|---|---|---|
| Campaign | Top-level campaign or event | Winter Appeal 2025 |
| Team | A team within the campaign | Winter Appeal 2025: Melbourne Office Team |
| Fundraiser | An individual fundraiser's page | Winter Appeal 2025: Melbourne Office Team - Sarah's Run for Hope |
Note
Not every notification creates all three levels. A donation made directly to a campaign (without a fundraiser) links to the top-level campaign only.
Key fields set by MoveData#
| Field | Description |
|---|---|
| Name | Constructed from the platform data (see hierarchy examples above) |
| Status | Set from the platform (can be suppressed) |
| Start Date, End Date | Campaign dates from the platform |
| Parent Campaign | Links to the parent level in the hierarchy |
| Expected Revenue | Target amount if provided by the platform |
How MoveData finds existing campaigns#
MoveData matches campaigns using the platform key — a unique ID assigned by your fundraising platform. If a campaign with the same platform key already exists, MoveData updates it rather than creating a duplicate.
Note
If a donation comes in and the fundraising page does not yet exist in Salesforce, MoveData creates the campaign automatically. Records do not need to exist beforehand.
Campaign Members#
When MoveData links a person account to a campaign, it assigns a campaign member status. Statuses follow a one-way priority order — a person's status can move up but never down:
- Team Leader
- Fundraiser
- Recurring Donor
- Donor
- Prospect
For example, if a person account is already a Fundraiser and then makes a donation, their status stays as Fundraiser.
Gift Commitments and Gift Commitment Schedules#
When a supporter sets up a recurring donation, MoveData creates two records:
- A Gift Commitment to represent the ongoing commitment
- A Gift Commitment Schedule to store the frequency and schedule details
Each instalment received creates a separate Gift Transaction (see below).
Key fields set on Gift Commitment#
| Field | Description |
|---|---|
| Name | Generated name for the commitment |
| Donor | The recurring donor (person account) |
| Campaign | The associated campaign |
| Effective Start Date | When the recurring giving started |
| Status | Synced with the platform (see mapping below) |
| Schedule Type | Set to "Recurring" |
How MoveData finds existing gift commitments#
MoveData matches gift commitments using the platform key — a unique ID assigned by your fundraising platform. If a gift commitment with the same platform key already exists, MoveData updates it rather than creating a duplicate.
Status mapping#
| Platform status | Nonprofit Cloud status |
|---|---|
| Active | Active |
| Paused | Paused |
| Cancelled | Closed |
| Failed | Lapsed |
Frequency mapping#
| Platform frequency | Nonprofit Cloud value |
|---|---|
| Weekly | Weekly |
| Fortnightly | Every 2 Weeks |
| Monthly | Monthly |
| Quarterly | Every 3 Months |
| Half-yearly | Every 6 Months |
| Annually | Yearly |
Gift Transactions (Donations)#
Each individual donation creates a Gift Transaction record in Salesforce.
Key fields set by MoveData#
| Field | Description |
|---|---|
| Original Amount | Donation amount |
| Status | Transaction status |
| Transaction Date | Date the donation was made |
| Donor | The donor (person account) |
| Campaign | The campaign the donation is attributed to |
| Gift Commitment | Linked to the recurring commitment if applicable |
| Gift Commitment Schedule | Linked to the schedule if applicable |
| Payment Method | How the donation was paid (Credit Card, PayPal, etc.) |
| Payment Identifier | External payment reference |
How MoveData finds existing gift transactions#
MoveData matches gift transactions using the platform key — a unique ID assigned by your fundraising platform. If a gift transaction with the same platform key already exists, MoveData updates it rather than creating a duplicate.
Gift Refunds#
When your fundraising platform sends a refund notification, MoveData creates a Gift Refund record linked to the original Gift Transaction.
Refunds
When a refund is issued in your fundraising platform, MoveData creates a separate Gift Refund record linked to the original Gift Transaction.
Key fields set by MoveData#
| Field | Description |
|---|---|
| Gift Transaction | The original donation being refunded |
| Amount | The refund amount |
| Date | Date the refund was processed |
| Status | Typically set to "Completed" |
| Processor Transaction Fee | Any fee associated with the refund |
Gift Soft Credits#
Soft credits recognise people who helped bring in a donation, even though they are not the primary donor. In Nonprofit Cloud, MoveData creates native Gift Soft Credit records.
MoveData creates soft credits during post-processing, after the donation record is saved. It checks the campaign hierarchy and creates credits for contacts at each level:
- The campaign organiser — the primary contact on the top-level campaign
- The team captain if the fundraiser belongs to a team
- The fundraiser whose page the donation came through
Note
Soft credits do not change the donation amount or the primary donor. They give you a way to report on who drove fundraising results.
Further reading#
For the full technical field reference, see Nonprofit Cloud extension fields and objects.
Related articles#
- How the donation pipeline works
- Campaign attribution
- Recurring donations
- How soft credits work
- Duplicate rules
- Map to existing records: NPC
- Donation pipeline
- Your data in NPSP
- Nonprofit Cloud extension fields and objects
- Nonprofit Cloud extension settings
- Nonprofit Cloud licensing requirements
- Reading and understanding error messages