Your contact database isn't static. It's rotting. Not all at once—decay doesn't announce itself. A field gets deprecated and nobody updates the 2,000 existing records. A sync breaks for three weeks and you don't know which half of your contacts are out of sync. An automation orphans a deal because the field it was watching no longer exists. By the time you notice, the damage is already baked into your forecast, your campaigns, and your revenue operations. We've built systems to track this decay in large contact bases, and five patterns appear in almost every CRM we examine. Each one is detectable using tools already in your platform—no external audit required, no consultant needed. Here's what to look for, why it matters, and how to fix it. Pattern 1: Orphaned records that lost their parent A contact belongs to a company. A deal belongs to a contact. When the parent record gets deleted or merged, the child record doesn't automatically vanish—it lingers, now belonging to nothing. In large CRMs, orphaned records can account for 3–8% of your database. Why this matters: Orphaned contacts still appear in reports, still get counted in forecasts, and still eat your list limits. Orphaned deals still run in automations, triggering false activity logs and breaking revenue attribution. How to spot it: Run a report filtered by Company = Empty/Null and sort by creation date. If you have dozens of contacts with no company, especially old ones, they're probably orphans. Check your CRM's pipeline view . If you see deals with no associated contact name visible (a blank parent field), export that list and check the record IDs—these are orphans waiting to be archived. Query your largest deal-owning teams' pipelines and filter by Contact Status = Active but Contact Company = Null . Any records here are blocking real deals from visibility. The fix: Archive or merge them back. If the parent was deleted by mistake, recover it from your recycle bin (most CRMs keep deleted records for 30 days). If the merge was intentional, update the child records to point to the surviving parent before archiving the orphans. Pattern 2: Custom fields that nobody told the database were deprecated You renamed a field. You added a new one. You realized mid-rollout that a field was redundant and told the team to stop using it. But the old data still sits there—incomplete, inconsistent, sometimes contradicting the new field. Automations that reference the old field silently fail. Reports that display both fields confuse everyone about which one is real. Why this matters: Field sprawl degrades data quality by introducing contradictions. When two versions of the same data exist, your team picks whichever one seems right in the moment—and you end up with 60% of your contacts using one definition and 40% using another. How to spot it: Export your contact schema (the list of all fields). Scan it for naming patterns: do you have Website , Company Website , and Web URL ? Do you have Decision Maker , Primary Contact , and Key Stakeholder ? These are duplicates. In your CRM's field settings, check which custom fields have fewer than 20% of records populated . Low adoption often means the field was replaced by a newer one that people prefer. Pull a report of your top 10 automations. For each one, note which fields it reads and writes. If an automation reads from a field but your team stopped populating it six months ago, that field is stale—and so is the automation. The fix: Consolidate. Pick the authoritative field. Migrate the data from the old field into it (most CRMs have bulk-update tools or integrations that can do this). Archive the old field. Update any automations that reference it to use the new field. Document the change in your data dictionary so your team knows which fields are current. Pattern 3: Lookup fields with broken references A lookup field points to another record—a contact belongs to a company, a deal belongs to a contact. When you delete the referenced record (say, you soft-delete a company), the lookup should either cascade-delete the child or leave it pointing to nothing. Many platforms do neither cleanly. The lookup breaks, but the foreign key reference lingers, invisible and unindexed. Why this matters: Broken lookups corrupt reports and break automations that expect a valid parent. A deal report grouped by company will show a "(blank)" row that shouldn't exist. An automation that tries to update the parent company will fail silently. How to spot it: In your CRM, run a report on deals grouped by their related company . If you see a row labeled "(No value)" or "(Blank)" with more than a handful of deals, those are broken lookups. Export them. Create a filter: Contact Company is set but Company record does not exist (most CRMs let you query this via a "broken reference" condition). Any results are orphaned by a deleted parent. In your automation history or error logs, search for errors mentioning "invalid parent ID" or "reference not fo