How a Small Human-Services Nonprofit Stopped Donations from Silently Dropping Between Classy and Bloomerang with Zapier

How a small nonprofit fixed a Classy-to-Bloomerang Zapier sync that silently dropped gifts: ACH re-checks, retry handling, review queues, and event data.

Oct 14, 2026

How a Small Human-Services Nonprofit Stopped Donations from Silently Dropping Between Classy and Bloomerang with Zapier

TABLE OF CONTENTS

The situation

The problem: the Classy-to-Bloomerang sync worked, until it didn’t

What they'd already tried

Have a sync that "mostly works"?

TL;DR: A small (11–50 person) human-services nonprofit processing roughly 300–400 online transactions a month, including 150–200 recurring sustainer gifts, turned a Classy-to-Bloomerang sync that "hit or miss" dropped gifts into one where every transaction either lands in the CRM or lands in a review queue with an alert. The fixes covered ACH delays, payment retries, duplicate donors, and event season.

Classy to Bloomerang Zapier sync for nonprofit donations. Photo by Markus Winkler on Unsplash

The situation

The organization is a small human-services nonprofit with a lean development team: a development lead, a database and gift-processing staffer, and a part-time development associate. Online giving runs through Classy (now GoFundMe Pro). Donor records, appeals, and acknowledgments live in Bloomerang. Zapier sits between them.

Volume is modest but steady, and spiky in the fall. In the team's own numbers, they see "over 300 transactions in a month" in a normal stretch, with 150–200 of those coming from a single recurring sustainer campaign. In the last four months of the year, an annual event adds around 200 ticket buyers, 100 silent-auction bidders, and 100 event-day donors on top of regular giving.

The problem: the Classy-to-Bloomerang sync worked, until it didn’t

Getting a basic Classy-to-Bloomerang Zap running was the easy part. Keeping it accurate turned out to be the real job.

A few weeks after the first version went live, the development lead put it plainly: "In the course of a day we would get, say, 10 donations and 2 of them would not flow." The missing gifts didn't share a campaign or a payment type, so there was no obvious pattern. Staff only found them by comparing Classy against Bloomerang by hand.

The failures that followed over the next year all had the same shape. Something legitimate happened in Classy, and the automation either ignored it, recorded it twice, or recorded it wrong:

Retried payments disappeared. When a donor's card failed and they tried again, Classy recorded the second attempt as an update to the original transaction, not a new one. The Zap was built to fire on new transactions, so the successful retry never reached the CRM.
ACH gifts got stuck in "pending." Bank transfers sit in a pending state for several days before clearing. The automation saw "pending," correctly refused to post it as a gift, and then never looked again. At one point the team had 64 transactions that had cleared in Classy but never reached Bloomerang. The question on the call was whether someone could "just pinpoint them and then rerun them easily," or whether staff would have to key them in manually.
Duplicate donor records. The Zap’s constituent lookup relied on exact matches against a donor’s primary email, phone, or address in Bloomerang. A donor with a summer address, or a street name written "Hill" in one place and "Hl" in another, or a nine-digit ZIP instead of five, came through as a brand-new constituent.
Event registrations only partly synced. A table captain registering eight guests came through as one constituent. The other eight never got records.

None of these failures were loud. The team found out when someone noticed a gap.

What they'd already tried

The team had set up Zapier themselves, expecting a simple connector between Classy and Bloomerang. A month in, the development lead said, "the skill level that is needed for it is above our knowledge base."

They had also gone straight to Classy support about the incomplete-transaction problem. The reply was a detailed technical email that, once unpacked, described exactly the update-versus-new-transaction behavior that was breaking their retries.

What we built

Over 28 working sessions spread across roughly 16 months, a Connex consultant (later joined by a second) worked live with the nonprofit’s staff in ZoomFlow sessions, building on a shared screen. The goal was not a bigger automation. It was an automation that can’t fail quietly.

1. A success-only path into the CRM. The core Zap posts only successful transactions to Bloomerang. It matches or creates the constituent and maps the campaign and appeal from the Classy campaign ID. Recurring gifts are routed to a dedicated sustaining appeal and recorded as individual gifts rather than pledges. A custom API call pulls answers that Zapier's standard Classy trigger doesn't expose, such as pronouns, birthdays, and tribute or dedication details.

2. A review queue for everything else. Any transaction that isn't successful (incomplete, failed, or pending) is written to a Zapier Table and triggers an email to staff. That one change turned "hit or miss" into a visible list: every gift is either in the CRM or in the queue.

3. A daily ACH re-check. Pending bank transfers get their own workflow. Once a day, it re-checks every pending record against Classy, fills in missing transaction IDs and donor emails, posts the gift to Bloomerang once it clears, and removes the record from the list automatically. Before this, the part-time associate cleared that list by hand. The same logic was used to work through the backlog of 64 pending-then-cleared gifts instead of re-keying them.

4. Guardrails against bad data. Filters drop zero-value and negative-amount transactions. Ticket sales carry gross amount, fair market value, and tax-deductible amount separately, so receipts are correct. Corporate gifts go to organization records instead of individual donor records.

5. Event handling. Ticket types (captain, ambassador, regular) are written onto the transaction. Captain-and-guest relationships are tracked in the CRM. A batch import catches guests who are added after the original registration, which Classy doesn't treat as a new transaction. The eight-guests-per-table gap was traced to the source API not returning attendee lists consistently on every transaction, which is a limit of the platform, not of the Zap.

6. Maintenance that doesn't need a consultant. When the platform deprecated its webhook app and changed API authentication, every affected Zap was updated and the errored runs were replayed. The consultant also recorded short training videos so staff can handle routine work themselves: duplicating a campaign Zap for a new appeal, swapping the campaign ID and appeal, reading an error, and replaying a failed run.

7. A donor welcome series. Once the data was trustworthy, the team added a multi-step welcome email series triggered from Bloomerang, with each email logged back to the donor record and unsubscribes written to the CRM.

The results

These are real figures from the engagement, not estimates. No dollar-savings figure is given, because the client never stated per-gift handling time and we won't make one up.

300–400 transactions a month flow automatically, including 150–200 recurring sustainer gifts, with campaign, appeal, payment method, and tribute data attached.
No more silent drops. Every non-successful transaction now lands in a review table with an email alert, instead of being discovered when someone spots a gap. The original failure pattern, by the client's own description roughly 2 of 10 gifts on a bad day, went from invisible to tracked.
64 stuck ACH gifts reconciled by automation instead of manual re-entry, and new ACH gifts clear themselves daily.
Event season without data cleanup. Ticket type, fair market value, and guest relationships arrive structured, ahead of the fall surge of roughly 400 event transactions.
Predictable automation costs. The team now knows each transaction uses about six Zapier tasks. When usage spiked to 1,099 tasks in a single day, the consultant traced it to the sustainer campaign issues of that period. Plan sizing for event season is now a calculation instead of a surprise overage.
Staff can maintain it. Routine changes like new appeals and replaying errors are handled in-house using the recorded walkthroughs.

Client voice

On the daily ACH re-check that replaced manual list-clearing, the part-time development associate said: "That's super helpful, because... I only work part-time, so it takes a big chunk of my time to go find them if it keeps happening."

FAQ

Will this work with our existing tools? Yes. This was built entirely on the client's existing Classy, Bloomerang, and Zapier accounts. Nothing was replaced. Where Zapier's standard triggers didn't expose a field, a direct API call filled the gap.

How fast was the first measurable win? The core sync and the failed-transaction queue were in place within the first few weeks. The ACH, event, and email work came later as each edge case showed up in real giving data.

What access did it need? Admin access to Zapier, plus API credentials for Classy and Bloomerang. Staff kept ownership of every account, and the team was on the call for most sessions.

What if the donation platform changes something? It will. In this engagement, a deprecated webhook app and an authentication change each broke a set of Zaps. Because failures go to a queue and alert staff, those breaks were caught and replayed instead of losing gifts.

Have a sync that "mostly works"?

If your giving platform and CRM are connected but someone still has to compare the two to find missing gifts, that’s the problem this solves. We fix syncs like this live with your team, on the accounts you already have, so every gift either lands in your CRM or shows up in a queue. Book a free call with Connex to walk through your setup.

Shopify product customization: variants and file uploads