When an Integration Issue Is Really a Data Quality Issue

By Stacey Segal, COO

Not every integration issue is really an integration issue. Sometimes the connection is working. The file is moving. The API is responding. The scheduled process is running. The data is being transferred from one system to another.

And still, the results are wrong.

Records fail. Constituents duplicate. Gifts reject. Campaign values do not match. Required fields are missing. One system says the process worked, while the CRM tells a different story. It is easy to blame the integration. But often, the integration is only exposing a data quality problem that already existed.

Successful Movement Is Not the Same as Good Data

An integration can move data exactly as designed and still produce messy results.

If the source system sends incomplete names, outdated addresses, invalid codes, duplicate records, or inconsistent formats, the receiving system must deal with these issues.

The integration did not create the problem. It revealed it. That is why teams should look beyond the integration's technical status. “It ran successfully” only tells you that the process completed. It does not tell you whether the data was complete, valid, matched correctly, or useful.

Matching Problems Are Often Data Problems

Many integration issues show up during constituent matching. A record may fail because the email address is missing. A new constituent may be created because the name is formatted differently. A match may be uncertain because the address is outdated. A duplicate may appear because the source system lacks sufficient identifying information. These are not just integration logic questions. They are data quality questions.

Before changing the matching rules, ask whether the source data is sufficient to support better matching. If key identifiers are missing or inconsistent, even a well-designed integration will struggle.

Code Values Need Governance

Another common failure point is code tables. Campaigns, funds, appeals, designations, event types, constituent codes, source values, and other coded fields need to align across systems.

If the source system sends values that the CRM does not recognize, records may fail or end up in the wrong place. If similar values are used inconsistently, reporting may become unreliable. The fix is not just technical mapping. It is governance.

Someone needs to own code values, approve new ones, retire old ones, and make sure source systems use the right standards.

Exceptions Are Clues

Failed records are frustrating, but they are useful. Every exception tells you something about the data or process. Is a required field missing? Is a value invalid? Is a record ambiguous? Is the same source system creating the same error repeatedly? Is the upstream process collecting enough information?

Instead of treating exceptions as cleanup chores, treat them as signals. Recurring exceptions often point to a process that needs attention.

Summary

An integration issue is not always caused by the integration. Sometimes the integration is doing exactly what it should: showing where the data is incomplete, inconsistent, outdated, or poorly governed.

Before rebuilding the integration, look at the data feeding it. Better source data, clearer rules, stronger validation, and regular exception review can often solve the real problem.

Because the goal is not just to move data. The goal is to move data that your CRM can trust.