You have a CRM, accounting software, an email marketing platform, and a website, and none of them talk to each other. So when someone donates through your website, you type the gift into the CRM by hand. When you send an appeal, you export a list from the CRM and upload it to your email tool. When someone signs up to volunteer, they land on a spreadsheet that never makes it back into the CRM at all. That is integration failure, and it is worth being precise about what kind of problem it is. It is not a technology problem, it is a friction problem. Manual work between systems is friction, friction produces errors, errors produce bad data, and bad data makes every decision you take on top of it unreliable. This lesson teaches three ways to remove that friction: native integrations, an automation platform such as Zapier, and manual processes run with real discipline. Not everything needs automating; sometimes the disciplined manual process is the right answer.

Why Integration Matters

Data about one person lives in many places at once. A donor's name sits in your CRM, their payment history in accounting, their email engagement in your email tool, and their event attendance in your program database. Integration means those systems share what they know instead of treating one supporter as four unrelated people. The benefit shows up in three places. Reporting becomes real time, so you can ask "how many active donors gave more than last year?" and get an answer that is current rather than one that was true whenever someone last exported a file. Segmentation improves, because email lists reflect what the CRM knows today. And errors drop, because data is entered once and used everywhere.

There is a cost on the other side of the ledger. Integration takes setup time. It creates maintenance overhead, because connections drift, credentials expire, and field names change underneath you. It also creates coupling: when one system breaks, it can break the system connected to it, and a failure that used to be contained now propagates. None of that is an argument against integrating, only for integrating deliberately, starting with the flows that hurt most and knowing what you have signed up to maintain.

Approach One: Native Integrations

Some tools ship with built-in connectors to the other tools you already use. HubSpot connects directly to Stripe. Salesforce connects to QuickBooks. Google Forms writes responses into Google Sheets without anyone configuring anything. These are the easiest integrations available to you and they should always be the first thing you check. There is no middleware to buy or learn, they are usually free or already included in the subscription you pay for, and setup is often literally a matter of clicking "connect" and authorising the two accounts. Once connected, data flows on its own.

The limitation is simple: a native integration only exists if both vendors built it, and not every pair of tools has one. That fact has a consequence for how you buy software. When you evaluate a new tool, ask whether it integrates with the systems you already run. If it does not, that is a point against it. Integration ease belongs in your selection criteria alongside price and features, because a tool that cannot talk to anything quietly adds manual work to somebody's week forever.

Integrations that commonly exist for nonprofit tool stacks include:

• Donation platforms into the CRM, such as Stripe into HubSpot, or Donorbox into your CRM
• Email platforms into the CRM, such as Mailchimp into HubSpot, or Klaviyo into your CRM
• Forms into a database, such as Google Forms into Airtable, or Typeform into your CRM
• Calendar into email, such as Google Calendar into Gmail
• CRM into accounting, such as HubSpot into QuickBooks

If your particular pair of tools has no native connector, you move to the second approach rather than giving up on the flow.

Approach Two: Automation Platforms Such as Zapier

Zapier is a middleman. It watches tool A for a trigger, such as a new donation or a form submission, and when that trigger fires it sends the data on to tool B as an action. Make, formerly Integromat, does the same job. In practice that looks like this: someone donates through Stripe, which is the trigger, and Zapier creates a contact in your CRM, which is the action. Someone fills out a volunteer form, which is the trigger, and Zapier appends a row to a Google Sheet, which is the action. Setup is no-code. You define when X happens in tool A, do Y in tool B, and the platform handles the plumbing between them.

Cost depends on how much you push through it. The Zapier free tier is limited, allowing five tasks and running them with delays, and the standard plan is priced depending on task volume. The limitations matter more than the price for most organisations. Zapier cannot do everything: if the data format on one side does not match the other side cleanly, complex transformations start to require custom code. Some sensitive data, credit card details being the obvious case, should not be routed through a third-party automation platform at all. And the platform becomes a dependency, because when it is down your integration is down with it.

The way to use this well is to map your most critical workflows first and automate those. Donation into CRM. Volunteer signup into the volunteer database. Form submission into a notification email for whoever must act on it. Those connections remove the most repetitive manual work, so start there rather than with whatever is easiest to build. Then build exactly one integration, get it working, and only then add the next. Connecting everything in a single push is how organisations end up with five half-configured flows and no idea which are running.

Approach Three: Manual Process With Discipline

Sometimes integration is overkill, and it is worth doing the arithmetic honestly. Say you take 30 new donors a month and entering them into the CRM by hand takes 1 hour. A Zapier integration takes 2 hours to set up and about 5 minutes of maintenance a month. Is it worth it? Probably yes, on those numbers. But only if you will actually do the setup. If your honest answer is "we should integrate this eventually," you will not, and a clear manual process you genuinely run beats an automation you never build.

Manual processes that work in practice share the same shape: a named owner, a fixed slot in the calendar, and a known duration. A weekly donor export where every Monday someone pulls donations out of Stripe and imports them into the CRM takes about 30 minutes and works because it is scheduled. A monthly report compilation where finance exports accounting data, development exports donation data, and programs exports program data, with one person combining them into a single report, takes around 2 hours and is not automated but is entirely predictable. A volunteer check-in where every Tuesday someone logs hours from paper sheets into the database takes about 1 hour and is manual but disciplined.

The key is in that last word. Schedule it, give it an owner, and do it consistently. Manual is not the problem; haphazard is the problem. A process you run some months and skip others produces data that is inconsistent in ways nobody can see from the inside, which is worse than either full automation or reliable manual entry. As a rule of thumb, for low-volume processes manual is fine, for high-volume processes running to hundreds of transactions weekly you should automate, and for the middle ground of tens per week the deciding factor is your team's capacity rather than the technology.

Choosing Between the Three

The three approaches are not a ladder you climb. They are options you pick between per data flow, and a healthy tech stack usually runs all three at once. The table below summarises how they differ on the dimensions that decide the choice.

Building an Integration Strategy

Do not integrate randomly, because random integration produces exactly the maintenance burden without the benefit. Map your data flows first. List all your tools. List the data that needs to move between them, which is a more useful question than it sounds: do donors need to move from the website to the CRM, volunteers from a form to the database, revenue from Stripe into accounting? Rank those flows by impact, asking which would save the most time or prevent the most errors. Then evaluate feasibility for each one, deciding whether it is served by a native integration, an automation platform, or a manual routine. Finally plan the implementation order, and choose something relatively simple and high impact first so the work builds momentum instead of stalling.

Worked through for a food bank, that map might come out as follows: the website donation form into the CRM by native integration if one exists and otherwise through Zapier; the CRM into accounting by native integration; the volunteer form into the volunteer management database by native integration or Zapier; and the program database into the monthly impact report manually, by exporting program numbers and compiling them with everything else. The sequencing then follows from the ranking. Start with the donation flow, because it is critical and often the most straightforward to build. Get that working and observed. Then move to volunteer management, and take on the reporting integrations last.

Testing Your Integrations

Before an integration goes live, test it rather than assuming the setup wizard told you the truth. Send test data through and check three things: does it arrive, does it arrive without creating duplicates, and does it preserve the information that matters downstream. For a donation flow, put a test donation through and confirm it appears in the CRM correctly, that it is matched to the existing donor record rather than creating a second copy of that person, and that the amount came across intact. For a form, fill it out yourself and confirm the submission lands in the destination in the shape you expected.

Then run the integration quietly for a week before you make it official and turn off whatever manual process it replaces. The reason is straightforward: if something is broken, you would rather find out across 10 test records than across 1,000 real ones. Cleaning up a duplicated donor file after a month of unattended syncing costs far more than the week of overlap you saved by skipping the trial.

When to Pay Someone to Build a Custom Integration

If your tools have no native integration and the automation platform genuinely cannot do what you need, the remaining option is custom code, where a developer writes an integration against the two systems' APIs. The cost varies depending on complexity. Set the bar high before you go there. Custom integration is justified when the manual workaround is genuinely painful, on the order of 10 or more hours weekly, and when the tools you need to connect have no viable alternatives you could switch to instead. Most nonprofits should never reach that point. Native integrations, an automation platform, and disciplined manual processes between them cover about 95% of use cases, and the small remainder is usually a sign that one of the tools is the wrong tool.

Anti-Patterns

Five failure modes account for most integration disappointment in small organisations. Each is cheap to avoid in advance and expensive to unwind later.

• Integrating too early. You have just bought a new CRM, your data is messy, and you want to connect it to everything immediately. Clean the data first, then integrate. Garbage in, garbage out applies to integration as much as to anything else, and an automated flow will replicate your duplicates faster than a human ever could.
• Integrating without understanding the impact. Spending 10 hours to build a Zapier flow that saves someone 1 hour of work per month means you break even in 10 months. That can be a perfectly reasonable trade, but it should be a decision you made rather than one you discovered. Do not integrate for integration's sake.
• Creating a dependency nobody understands. Someone sets up a flow, then leaves. Six months later it breaks and nobody knows how it worked. Document each integration: who built it, why, what data moves, what breaks if it fails.
• Not handling errors. Integrations fail. The platform cannot reach the API, a webhook times out, donor data gets duplicated. Plan for it with error handling, such as an alert to a named inbox when data does not import cleanly, rather than hoping.
• Treating integration as the finish line. Integration reduces manual work, it does not remove the need for discipline. You still have to maintain data quality, review reports for anomalies, and check monthly that the connection is still running.

Practice Prompts

Work through these with whoever owns your systems. Each produces an artefact you can keep rather than just a conversation.

• List every tool you use and, next to each, the data that moves in or out of it by hand. Mark which transfers somebody actually performs and which are aspirational.
• Rank the manual transfers by how much time they consume and how often they produce errors. Circle the top three, since those are your integration candidates.
• For each of the three, check whether a native integration exists before you look at anything else, and write down what you find.
• Take your highest-ranked flow and estimate both sides of the trade: hours to set up, minutes of monthly maintenance, and hours of manual work saved per month. Decide from those numbers rather than from enthusiasm.
• Document an integration you already run: who built it, why, what data flows, what breaks if it fails. If you cannot answer all four, you have found a risk.
• Design a test plan for your next integration: the test record you will send, what you will check on arrival, and how long you will run it in parallel.
• Pick one manual process you intend to keep and make it disciplined: name the owner, fix the day, estimate the duration, and put it in a shared calendar.

Reflection

Think about the last time you or a colleague retyped information from one system into another. How long did it take, how often does it happen, and what would have gone wrong if it had been skipped for a stretch? Then ask the harder question: would anyone have noticed? Most integration problems in small organisations are invisible rather than dramatic, because the cost spreads thinly across many people and never lands anywhere large enough to prompt action. Consider too which of your existing connections you could not explain to a new colleague today.

Glossary

• Native integration. A connector built by the vendors themselves between two specific tools, typically enabled by authorising both accounts and usually included in the subscription.
• Automation platform. A third-party service such as Zapier or Make that sits between two tools, watching one for events and performing actions in the other.
• Trigger. The event in the source tool that starts an automated flow, such as a new donation or a form submission.
• Action. The step the automation platform performs in the destination tool once a trigger fires, such as creating a contact or adding a row.
• API. The programmatic interface a tool exposes so other software can read and write its data, which is what a developer works against when building a custom integration.
• Webhook. A message one system sends to another the moment an event happens, used to push data across without waiting for a scheduled check.
• Disciplined manual process. A transfer performed by a person, with a named owner, a fixed schedule, and a documented set of steps, as distinct from ad hoc retyping.

Related Lessons

The instruction to clean your data before connecting anything to it is worked out in full in Data Quality for Nonprofits: The CRM Hygiene Guide, and it is the prerequisite for most of this lesson. Decisions about which tools you own in the first place, where integration ease belongs in your selection criteria, are covered in Building Your Nonprofit Tech Stack on a Budget and CRM Selection Guide for Nonprofits: Beyond the Feature Checklist. If you are still working out which gaps in your systems deserve attention first, start with The Nonprofit Technology Assessment: Where Are Your Gaps?. Questions about data passing through third-party services, raised above in the discussion of automation platforms, are treated properly in Third-Party Vendor Risk: Protecting Data Across Your Tool Chain. Two neighbouring lessons complete the picture: Moving to the Cloud: A Nonprofit Migration Guide for the infrastructure side, and The Nonprofit Website That Converts: Design Principles for the donation form that feeds your most important integration.

Closing

Integration is about reducing friction so your data arrives where it needs to be without a person carrying it there. Start with native integrations, which are free and easy where they exist. Add an automation platform to cover the gaps, which is relatively cheap and needs no code. Keep manual processes where they make sense, but make them disciplined ones with an owner and a date. Above all, do not over-engineer. You need your tools talking to each other; you do not need them talking perfectly. Getting 80% of the way to automation is far better than 0%, and considerably better than reaching for 100% and failing.

Key Takeaways

• Integration failure is a friction problem, not a technology problem. Manual work between systems creates errors, errors create bad data, and bad data makes decisions unreliable.
• Check for a native integration first. It is usually free, needs no configuration beyond authorising both accounts, and only fails to exist because one of the vendors did not build it.
• An automation platform covers the gaps with no code, at a cost that scales with task volume, but it becomes a dependency and should not carry your most sensitive data.
• A disciplined manual process beats an automation you never build. Schedule it, give it an owner, and run it consistently.
• Map and rank your data flows before building anything, then implement one at a time starting with something simple and high impact.
• Test with sample records and run in parallel for a week. Catching a fault across 10 test records is cheap; catching it across 1,000 real ones is not.
• Custom code is justified only when the manual workaround runs to 10 or more hours weekly and no alternative tools exist. Native integrations, automation platforms, and manual discipline cover about 95% of cases.
• Document every integration and monitor it monthly. An undocumented flow becomes an outage nobody can diagnose once its author leaves.

Frequently Asked Questions

Is Zapier reliable enough for critical nonprofit operations? Mostly yes. Zapier publishes a 99.5% uptime SLA, which works out at roughly 3.5 hours of downtime per year, and at nonprofit scale that is usually acceptable. But if an integration is truly critical, in the sense that you cannot afford to miss a single donation, build yourself a fallback. Monitor the platform's status page, set up error notifications so failures reach a person, and add a weekly manual check that data is still flowing.

If we use Zapier, is our data going through Zapier's servers? Yes. Data passes through the platform's infrastructure temporarily, usually for a matter of seconds. If you handle sensitive data such as health information or financial details, that transit may be a concern worth raising. Zapier encrypts data in transit and complies with GDPR and HIPAA where relevant. But if your organisation is extremely sensitive about information moving through third parties at all, you need custom code or native integrations only, and that is a decision to make before you build.

What is the difference between Zapier and Make or Integromat? They do similar things. Zapier offers more integrations, over 3,000 of them, and better-documented templates. Make is more flexible for complex workflows. For most nonprofits Zapier is the easier starting point, and both are sound choices. Pick one and stay with it, because switching later means rebuilding every flow you have.

Should we always choose tools that integrate with each other? It is a factor, not the only factor. Sometimes the best CRM for your mission does not integrate with your accounting software, and that is acceptable: bridge the gap with an automation platform or a disciplined monthly sync. Do not let integration concerns stop you choosing the best tool for your core need. But between two tools that are otherwise equally good, let integration be the tiebreaker.

How do we know if an integration is actually working? Set up monitoring rather than assuming. For donation integrations, compare the number of donations in the payment platform against the number in the CRM every week. For form integrations, spot-check that randomly chosen submissions appear in the destination. For email integrations, verify that unsubscribes recorded in the email tool have synced back to the CRM. The habit that matters is verification on a schedule, monthly at minimum, because integrations tend to fail silently and the cost of a silent failure compounds with every week it goes unnoticed.