The Thank-You Automation That Blocked Donations: Why Flows Need Fault Paths
A record-triggered flow with no fault path doesn't just fail quietly — it can roll back the donation that triggered it. A real failure story and the fixes.
A nonprofit client had a nice piece of automation: when a donation was entered, a flow created a thank-you card task so a volunteer could send a handwritten note. Donor-retention gold. It had been built by an earlier contractor, iterated through seventeen versions, and then the builder moved on.
Months later, donations started failing to save. Not all of them — just some, with an error message nobody could interpret, deep enough in the stack that the online giving sync reported it as its failure. The gift processor had the money; Salesforce refused the record.
The culprit was the thank-you card flow. Not because thank-you automation is risky — because of how flows fail when nobody plans for failure.
The mechanism: an unhandled flow error rolls back the record
A record-triggered flow runs inside the same transaction as the record change that triggered it. When a flow element fails and there’s no fault path, the whole transaction fails — including the donation insert that started it. Salesforce doesn’t save the gift and then shrug at the broken automation; it unwinds everything.
So a bug in a nice-to-have feature (a greeting card!) becomes a hard outage in a must-have one (recording revenue). The donor was charged. The CRM refused to know about it. That’s the worst possible direction for the failure to flow.
What was actually wrong, bug by bug
Every one of these is common; this org just had the full set:
A hardcoded person. The card task was assigned to a named staff member — and she had left. Some paths referenced her by name, one by user Id. Flows that hardcode people are time bombs with a fuse exactly as long as that person’s tenure.
An Id compared to a name. One decision element compared an Id field to a text name. That condition can never be true — the branch it guarded had silently never run. Nobody knew, because false-and-quiet looks identical to working.
Dead throttle logic. A “don’t send another card within 90 days” check read a field that nothing populated anymore. Half-removed logic doesn’t just do nothing — it confuses everyone who reads the flow later and hides which parts are load-bearing.
Abandoned versions and orphaned drafts. Seventeen versions of one flow, plus two sibling flows in Draft and Invalid Draft states. When the builder leaves, nobody can tell intent from debris.
The fixes that matter
Add a fault path to every element that touches data. Connect the fault connector to something boring: create an error log record, post to a Chatter group, email an admin. The point is that the flow absorbs its own failure and lets the donation save. A missed greeting card should never cost you a gift record.
Run after-save and asynchronous when the work isn’t critical. A thank-you task doesn’t need to live inside the donation’s transaction. An asynchronous path runs after the record is safely committed — the automation can fail all it wants without touching the gift.
Never hardcode people. Assign to a queue, look the user up from a custom setting or a role, or use a public group. Ask of every flow: what happens the day this person leaves? If the answer is “it breaks,” it’s already broken — you just haven’t hit the date yet.
Deactivate and label the debris. Old versions, abandoned drafts, experiments — deactivate them and put the status in the description. The next admin (possibly volunteer, possibly you in two years) needs to know what’s real.
The pattern behind the story
Most small nonprofits inherit their automation: a contractor, a skilled volunteer, a long-gone staff member who was “good with computers.” The automation outlives its author, and nobody on staff can safely touch it — so it runs until it breaks something visible. If that’s your org, the cheapest insurance is an afternoon of review: list every active flow, ask what each one does, who it assigns work to, and what happens when it fails. The answers are usually fixable in hours. Finding them during a failed donation run is not.
I’m Chris Moore — an independent consultant in Henderson, NV. I untangle inherited Salesforce automation for small nonprofits, including pro-bono engagements through Catchafire and Taproot. If you’ve got flows nobody on staff dares to open, get in touch.