For Non-Profit IT: How to Build a Fundraising Data Foundation

If you run data or IT at a non-profit, you already know where the fundraising team’s questions tend to end up: with you. The donor picture is spread across a CRM, a finance system, a marketing platform, an events tool, and a few spreadsheets nobody can quite retire, and none of them were built to answer a question together. So every campaign, board report, and major-gift cycle becomes a custom data pull, and that queue is never empty. Whether you’re a team of one or of many, keeping the data usable competes with everything else you own.

The solution has two parts:

1. A data foundation, a single governed place that pulls those scattered sources together and makes them consistent, so a donor, a gift, or a campaign resolves to the same thing everywhere.

2. An AI agent that sits on top of that foundation, so the fundraising team can ask their own questions of the data instead of routing each one through you.

In our approach, that data foundation is Microsoft Fabric, and that agent is our Fundraising Intelligence Agent. The foundation is where everything rests, so that is where the build starts.

The point of the preconfigured solution is that a good deal of the plumbing is already built. The medallion lakehouse, the ingestion pipelines and notebooks, the sector data model, and the prebuilt fundraising reports and semantic model are included. By default, the ingestion targets two sources: Salesforce Nonprofit Success Pack, and Microsoft Dynamics 365 Sales through the Common Data Model for Nonprofits in Dataverse. If one of those is your system of record and the data is reasonably clean, a large part of the first mile is done for you. If it isn’t, and many non-profits run Raiser’s Edge, Bloomerang, DonorPerfect, or some mix, connecting them is work you own: a pipeline or a shortcut per source, mapped into the same model. The same holds for the data the fundraising model doesn’t already cover, such as marketing engagement, events, and finance. The honest read is that the solution gives you a strong starting structure, not a finished integration for every system you run.

Because the data is donor data, governance can’t be an afterthought bolted onto each report. On this foundation it can live in the layer itself: lineage that traces a number back to its source, role-based access that decides who sees what, sensitivity labeling, and the consent and retention rules a donor-data estate has to honor. Anything built above it, the agent included, inherits that trail rather than reinventing it. For a team that has fielded a where-did-this-number-come-from question in an audit or a data-subject request, this is the part that turns a pile of connected data into something defensible.

We have built this kind of governed foundation on Microsoft Fabric for Amnesty International, the world’s largest human-rights organization, as the central data platform behind their research. Their Head of IT Business Systems, Mira Mistri, has described the result as, “Having data in a central place gives us more accurate and better reporting, better data governance, and master data management..”

There are two ways to stand up the preconfigured solution. The path Microsoft recommends is the Fabric workload interface. There is also a scripted path, a PowerShell installation that deploys the lakehouses, notebooks, pipelines, triggers, reports, and semantic models into your workspace. Either way you need an active Fabric capacity and workspace, and the scripted route expects PowerShell 7, Python 3.10 or later, and the Fabric CLI. A couple of specifics are worth knowing up front: connecting Dynamics data means linking your Dataverse environment to Fabric and using Common Data Model for Nonprofits version 3.1.3.4 or later, with change tracking enabled on the tables you sync. You can deploy with the included sample data first, which lets you stand the whole thing up and watch the reports populate without touching a production system. The solution is open source, so the code, the data models, and the deployment scripts all live in Microsoft’s Nonprofits repository on GitHub, the fastest way for your team to see exactly what it does before committing to anything.

How long it takes depends almost entirely on your sources. When the source is one the solution already targets and the data is reasonably clean, the preconfigured pipelines and semantic model can compress what used to be a multi-quarter build into a matter of weeks. An early adopter interviewed in a recent webinar we co-hosted with Microsoft, La Ligue Contre Le Cancer, had its data team stand up a working donor data dashboard in two weeks. That figure is real but conditional. Sources the solution doesn’t cover, data that needs cleaning, and the governance and adoption work around the edges are all yours, and none of it is a switch you flip. The preconfiguration saves you the scaffolding, not the judgment.

For a data or IT team, this is less a build from scratch than an assembly: a preconfigured Microsoft Fabric foundation, your own connections to the systems it doesn’t already reach, governance carried in the layer, and an agent added last, in that order. The parts that are done for you are real, and so is the part that stays yours. The foundation is what everything else stands on, and it is the part your team would own, which is reason enough to look closely and work out, on your own terms, what it would actually take.