Every new software tool demo follows the same script: connect your data, watch the insights appear. Turn on the prospect scoring model, and it tells you who's ready for a major gift ask. Turn on the integration, and your online giving platform starts talking to your database automatically. It looks like magic, and for organizations with clean, well-governed data, it basically is.

For everyone else, it's a mirror…and sometimes not a very flattering one.

You already know why clean data matters. Reporting accuracy, segmentation, and the basic ability to trust a number in a standard report. What is new now is the third-party layer sitting on top of your data, and how it behaves.

A human can pick and choose what data to use in their analysis, while AI tools pattern-match across your entire dataset. A gift officer looking at a constituent record mentally filters out the weird code nobody's used since 2019 and the note that is difficult to interpret because someone just cut and pasted a 15-email conversation chain into the text box. An AI model doesn't have that instinct. It doesn't know which parts of your database are historical detritus and which parts are load-bearing.

Integrations are pipes, not filters. A pipe moves whatever's put into it. If the data going in is inconsistent, the inconsistency doesn't get cleaned up in transit. It is delivered intact to every connected system. And increasingly, it doesn't just flow in one direction. 

AI-generated scores and suggestions built on messy data don't just underperform. They look authoritative. This is the part that should actually worry you more than a broken report. A bad report looks bad; someone catches it. A confidently wrong capacity score, delivered as a clean number in a slick dashboard, doesn't announce that it's wrong. Leadership acts on it anyway, because it looks exactly as credible as a correct one.

Third-party tools expect specific structures to integrate cleanly, but organizations sometimes don’t discover this until mid-implementation. Not all solutions will automatically share the exact data mapping they offer before you sign a contract, which can cause issues mid-implementation.

A note on examples: this article is written for database managers broadly, but several of the concrete examples below are drawn from real, published integration documentation for Blackbaud Raiser's Edge NXT®specifically. The underlying mechanics (write-back sync, name/email matching logic, custom-field-only mapping) appear in most CRM ecosystems in some form. I'm naming the Raiser’s Edge-specific vendors because seeing the mechanics in detail is more useful than a vague mention of “some integrations.”

This is the single highest-leverage thing you can do, and it's mostly a permissions problem, not a data problem. Go into your user security settings and limit the ability to create new fields (and to add new entries in existing tables, like phone types) to the smallest group of people you trust to consider downstream consequences before they click “add.”

Why it matters here: Every uncontrolled new value is one more thing a predictive model has to treat as meaningful, and one more thing an integration's field mapping has to account for or silently mishandle. A phone-type table with six values is auditable. One with 40, half of them created by well-meaning temp staff during a single gala season, is not. “Richard’s assistant” should not be a phone type.

Free text is where information goes to die, becoming unsearchable. It's a pain to audit, a pain to report on, and a pain to clean up after the fact.

I learned this the hard way after Blackbaud's 2020 security incident. Part of my organization’s response involved searching the entire database for notes containing certain sensitive keywords; personal information that shouldn't have been sitting in unstructured text fields to begin with. There was no clean way to isolate it. It meant exporting every note on every record I flagged and combing through them manually, keyword by keyword, because nothing about the field was structured enough to search properly.

Why it matters here: AI tools will happily summarize or act on the contents of a notes field without any idea whether that field is governed, current, or even accurate. Several Raiser’s Edge NXT integrations sync notes and interaction content directly as-is (Instrumentl maps Notes fields explicitly; EverTrue pulls interaction summaries and bodies verbatim), which means whatever's sitting in that field, dated, sensitive, or simply wrong, moves into another connected system exactly as written, with nobody checking it along the way. 

Write them down. Put them in your procedures handbook. Actually follow them; for appeal codes, opportunity names, packages, events, campaigns, all of it.

Why it matters here: “Spring24,” “Spring 2024,” and “SP24-mail” look like three data points to a model that's trying to learn something from your appeal performance. They're really one appeal, fragmented into pieces too small to show a pattern. Additionally, embracing appeal and package structures will group your solicitation methods to create truly actionable reports. Any integration that matches or deduplicates by name is only as reliable as your naming discipline. That's not a hypothetical concern. 

Pick a rule and apply it consistently. For example, three months after the end of the fiscal year, mark all of last year's appeals inactive. That way, a gift can't accidentally land against the wrong appeal and quietly distort your reporting.

Why it matters here: An automated sync or an AI-assisted gift-entry workflow has no judgment to apply. It doesn't pause and think, “Should this appeal for the 2023 gala still be accepting gifts?” It'll add the gift to whatever's still marked active. 

Fewer phone types. Fewer constituent codes. Fewer everything please. If you've got more than 20 constituent codes, it's worth asking whether some of them should actually be attributes or special codes rather than a sprawling list of near-duplicates.

Why it matters here: Every extra table entry is one more thing a mapping configuration has to account for, and one more way a segmentation model can slice your data into groups too thin to mean anything. Twenty overlapping constituent codes with no standard hierarchy just give a model more categories to get confused across.

Why it matters here: This is “integrations are pipes, not filters” in its most literal form. Your governance can't stop at what your staff types in, because a connected tool can degrade your structure without a single person touching a keyboard. If you don't know which of your integrations can add and edit, you don't actually know the full set of things that can change your data, which means you don't really have control over your own structure anymore, no matter how clean your entry procedures are. If you don't already have this mapped out, I put together a free CRM Data Flow Map template that walks you through documenting exactly this, source by source, so you can see at a glance which of your integrations read, write, or both.

Know the actual logic your integrations use to decide “is this an existing constituent or a new one?” Raisely's integration with Raiser’s Edge NXT, for example, dedupes incoming donor and fundraiser records by name and email. If a constituent has multiple email addresses and none is clearly flagged as primary, or if name formatting is inconsistent across your database, the matching logic doesn't throw an error — it just fails silently, creating a duplicate.

Why it matters here: The practical cost here is duplicate constituents accumulating in your database as long as the underlying formatting issue goes unfixed. Each duplicate splits that person's giving history across two records, which understates their lifetime giving, throws off wealth screening and prospect research, and can result in a donor receiving two acknowledgment letters (or two solicitations) instead of one. And because the integration quietly creates these on a rolling basis rather than flagging them, nobody notices until a gift officer stumbles upon them, or until year-end reporting doesn't reconcile and someone has to figure out why. 

Some integrations can only map their own custom fields to your custom fields, never to your core CRM fields. And some integrations reject entire field types outright: Instrumentl's Raiser’s Edge NXT mapping, as another example, doesn't support Y/N fields or picklists for custom field mapping at all.

Why it matters here: If you haven't built well-named custom fields ahead of time, or if your field is a type the integration doesn't support, the mapping cannot happen, full stop. No amount of sophistication on the AI or vendor side fixes a mapping that structurally can't be made.

Here is a list of documents every organization should have as part of its data governance:

Good structure gets amplified into genuinely useful automation and insight, while bad structure gets amplified into confident-looking nonsense that leadership acts on anyway.

Which means the people holding the line on database structure aren't doing low-level janitorial work while the “real” strategic work happens elsewhere. They're doing the work that determines whether any of the AI tools and third-party integrations your organization invested in are actually paying off. Otherwise, they are just adding a faster, more convincing way to be wrong.

Is your organization considering integrating a third-party tool with your Raiser’s Edge NXT database? Schedule a free 30-minute meeting with me to discuss your database’s readiness.

-MALLORY

Because somebody has to care about the data.

The ideas, expertise, and opinions here are mine. Claude helped me write them down.