Nonprofit Cloud · the programme split
Your payments carry no programme split.
Nonprofit Cloud only copies it inside Gift Entry.
The commitment says which programmes the money is for. The payments underneath it say nothing, the programme reports come out short, and there is no error anywhere. This is why, how to find the payments affected with one query, and the flow pattern that writes the split onto every payment, found while building fundraising for a UK charity.
Reviewed 27 October 2026.
The cause
Why are Gift Transaction Designations not created?
Salesforce documents that payments inherit the programme split of their commitment, and they do, inside Gift Entry. Create the payment any other way, by a flow, a screen, an integration or a data load, and it inherits nothing. Tested on both steps, each returned zero designations. The split has to be written onto every payment by your own automation.
The documented behaviour is in Salesforce’s Trailhead module on gift commitments, read on 27 October 2026, and the object model is in the Nonprofit Cloud Developer Guide. Neither says the inheritance is limited to Gift Entry.
Check your own org
How do you find the payments without a split?
Count the Gift Transaction records that have no Gift Transaction Designation at all. Any number above zero is money that counts towards a donor and towards no programme. Run the query below in the Developer Console query editor, then check how the payments it finds were created.
If the number is high, look at how those payments were created: through Gift Entry, or by something else. Everything that is not Gift Entry needs the pattern below.
The fix
How do you write the split onto every payment?
Keep the split on the Gift Commitment as Gift Default Designation records, and let a record triggered flow copy it onto each new Gift Transaction as Gift Transaction Designation rows. Then back fill the payments that arrived before the split, and give both flows a fault path. The last two parts cover the cases that break a simple version.
Keep the split on the promise
The split belongs on the Gift Commitment as Gift Default Designation records: one per programme, with ParentRecordId pointing at the commitment, GiftDesignationId at the programme and AllocatedPercentage for its share. The platform allows one row per programme per parent, so a second row for the same programme fails with a raw duplicate error. Enter the split in the same screen that records the promise, so a commitment never exists without one.
Write the split onto every payment as it is created
A record triggered flow on Gift Transaction, after save, reads the commitment’s default designations and builds one Gift Transaction Designation per programme: GiftTransactionId, GiftDesignationId, Percent and Amount. The last row takes the remainder rather than its own rounded share, so the parts always add up to the payment to the penny. Build the rows in a collection and insert them once, never inside the loop.
Back fill payments that arrived before the split
If the split is added after the payments, those payments keep no breakdown and nothing on screen says so. Trigger the back fill on the commitment, not on the designation: two designations saved together start two interviews, and neither can see what the other just created. Touch only payments with no breakdown, so an existing split is never silently rewritten.
Give both writers a fault path
When payments and a split are saved in the same transaction, both flows try to write the same rows and the platform’s unique key rejects the second. That is the correct outcome, because the rows already exist. Without a fault path the user gets a raw error and the save fails; with one the duplicate is dropped quietly.
What makes it worse
Four choices that look reasonable and are not.
Putting the split on the Opportunity
It looks like the natural place, because that is where the application is described. It inherits nothing: tested on both steps, Opportunity to Commitment and Commitment to Transaction, each returned zero designations outside Gift Entry.
A separate screen for allocating money
A standalone allocation option lets somebody split money that was never promised, and the two totals drift apart. Allocation belongs to the promise and nowhere else.
Rewriting an old split automatically
Changing how money already received is divided across programmes is a finance decision. Automation should fill the gaps and leave existing rows alone.
A custom object instead of the native ones
Native reports and the Data Processing Engine read Gift Transaction Designation. A custom substitute cuts the org off from both, and from whatever Salesforce later builds on the native object.
Asked often enough to answer here
Questions
Does Gift Entry create the designations by itself?
Yes. Processing a gift through Gift Entry creates the Gift Transaction Designation records from the defaults. The problem appears when payments are created any other way: by a flow, by a screen you built, by an integration or by a data load. Those paths need the pattern above.
Why does it matter if the split is missing?
Because programme income is read from the designation records. A payment with no designation counts towards the donor and the total, and towards no programme at all. Restricted funds and funder reports then come out short, and no error says why.
Can this be fixed without code?
Yes. Both writers are record triggered flows. There is no Apex in the pattern, only collection building, one insert per flow and a fault path on each.
This pattern is part of Fundraising essentials: €4,550 for 70 hours on the ten licences Salesforce donates to an eligible nonprofit, as stated on its Nonprofit Cloud pricing page in October 2026. How it was found is in the charity case study.
Serhii Skrypnyk · Senior Salesforce Administrator · 7 Salesforce certifications · on the platform since 2018. Reviewed 27 October 2026.
Read next
The question that usually comes after this one.
Case: Community charity, United Kingdom
Three colour coded spreadsheets became one fundraising system, with every payment split across programmes and committee scoring inside Salesforce.
Salesforce Consultant Hourly Rates, 2026
Salesforce consulting rates in 2026 by who does the work, from offshore teams to large integrators, in euros, next to fixed prices published with their hours.
Salesforce Permissions Audit: Fixed €650
Nine access risks a Salesforce permissions audit finds and why agents inherit them all. Check them yourself, or one fixed day at €650 against your exports.