A charity directory and a donor-management system describe different kinds of things. The directory contains organizations and their historical source fields. A donor CRM may contain supporters, interactions, gifts, and internal workflow information. Connecting the ideas requires careful field design, not simply putting everything into one table. This guide proposes a practical mapping approach for teams thinking about charity reference data. It describes a design pattern, not an active CRM integration or account feature provided by DonorAPI.com.
Keep charities separate from supporters
Begin by defining the entities your system needs to represent. A charity is an organization record. A donor could be a person or an organization in your own operational system. A gift is a separate event connecting appropriate parties and amounts. The uploaded dataset contains charity records; it does not supply private supporter contact details, donation histories, payment information, or consent records. Treating it as a donor list would misrepresent both the source and the purpose of the directory.
This distinction should appear in the field names. Prefer a clearly named charity-reference object over adding an unexplained charity score to every contact. If a supporter expresses interest in a cause, record that relationship as your own information with its own basis, rather than inferring it from a charity's classification. A useful data model makes the relationships explicit. It does not assume that an organization's category, historical score, or recorded leader describes the preferences or behavior of the people who may support it.
Use an organization key deliberately
The EIN is a practical source key in this collection because all 8,408 values are distinct. Preserve it as text and keep the original formatting available for display. A system may also have its own internal organization identifier, but the two serve different purposes. Your internal key supports your application; the source EIN helps you reference the uploaded record. Keeping both visible avoids treating a vendor-specific identifier as though it came from the original dataset.
Name matching should be a review aid, not the sole identity rule. The source includes repeated names with different EINs. A mapping process that merges by name could therefore combine unrelated financial observations or leadership entries. Before applying any merge, compare the identifiers and record why the relationship is justified. When the evidence is insufficient, preserve separate candidates. A controlled unresolved match is preferable to a confident merge that quietly corrupts the record and becomes difficult to reverse later.
Map fields with their units and definitions
A field mapping should state the source name, destination name, type, unit, and transformation. For example, an expense amount is a monetary observation, while an expense share is a fraction displayed as a percentage. A score is a numeric observation on the source's documented scale. These differences matter when a system displays, sorts, or summarizes values. If all numeric fields are treated alike, a ratio may appear as currency or an identifier may lose leading zeroes.
The 23-field dictionary gives a starting point for this exercise. Preserve the distinction between reported values and calculated display values. A rounded dollar amount can be useful in a dashboard, but it should not overwrite the underlying source string. Similarly, a site size label such as Mid-sized maps to the source value mid; that readable wording is a presentation choice. Documenting the mapping makes later exports, reviews, and troubleshooting much easier than relying on an undocumented convention remembered by one person.
Give provenance its own place in the model
A usable reference record should identify where the information came from and what historical context applies to it. For this collection, that context includes the May 2019 collection date and the metadata's statement that ratings are mostly from 2017. The exact rating year is not supplied per row. A destination system should therefore not populate a precise fiscal-year field by guessing. Store the collection context and leave unsupported detail explicitly unknown.
The W3C Data on the Web Best Practices provides a broader reference for practices such as supplying provenance and metadata. In a donor-system design, the practical lesson is to keep the source and meaning of a value available wherever the value is used. A score copied into a dashboard without its context can look like a current operational fact. The same number with its historical source label is a more accurate piece of reference information.
Preserve missing values and review states
Missing compensation is not zero compensation, and a blank tagline is not a substantive statement about an organization. Your destination model should retain that distinction rather than making every field appear filled. A display can say “not reported in source” while the stored source value remains blank. This lets users distinguish an unavailable observation from an actual numeric zero or a literal source string such as “N/A.” Clear missing-value handling is part of data quality, not an aesthetic inconvenience.
Review status should also be separate from the source data. A team might track whether someone has examined an organization, requested additional information, or completed a current check. Those are workflow observations created by the team; they are not facts supplied by the historical dataset. Use distinct fields and clear labels so that “reviewed internally” does not become “verified by Charity Navigator,” and a reference score does not automatically trigger a conclusion about eligibility or suitability.
Limit what reference data is allowed to decide
Historical charity information can support research and segmentation discussions, but it should not silently determine payment approval, receipting language, current tax treatment, or a donor's communication preferences. The source lacks the fields needed for those decisions. A robust workflow identifies which evidence is required for each action and treats missing evidence as a reason for review. It does not use a convenient historical field as a substitute simply because the application expects a yes-or-no answer.
Consider a hypothetical internal dashboard with an organization name, EIN, historical score, and review note. That dashboard can help a staff member understand which record is being discussed. It cannot, from those fields alone, verify a bank account or authenticate a donation request. Keeping the action boundary explicit is especially important when polished interfaces make information appear operationally ready. A well-labeled reference panel should help users ask the right question, not encourage them to skip a separate control because a number looks authoritative.
Make changes traceable and reversible
Before importing a large reference collection into another system, test a small set of varied records. Include a repeated name, a missing compensation field, a long description, a zero amount, and an unusual revenue value. Check that identifiers remain strings, text is preserved, and source context appears where expected. This is a proposed implementation test, not a feature that the static website performs on a visitor's CRM. The point is to challenge assumptions before they affect thousands of records.
Define how later updates should work. A new source observation should not silently replace an older value if retaining history matters to your workflow. Keep the source version, transformation rule, and review status identifiable. If a mapping error is discovered, you should be able to locate the affected records and reverse the transformation without guessing. This discipline also helps distinguish a genuine change in an organization's reported information from a change introduced by your own import or formatting process.
Connect meaning before connecting systems
The donor CRM guide and Donor API overview describe the site boundary and reference-data concepts. The essential design principle is to preserve meaning as information moves: charity versus donor, identifier versus name, historical observation versus current verification, and missing value versus zero. Getting those distinctions right is more valuable than a fast import that leaves every field populated but its interpretation uncertain. A useful connection begins with a clear model of what the records actually describe.
