Data Management How to find and fix the records that quietly break reporting: no owner, no company, duplicates.

Operations, Data, Data Management. Three tabs for finding and fixing broken records. You need the internal operations capability.

Bad data does not announce itself. It shows up as a forecast that is wrong, an automation that reaches nobody, or a customer nobody owns. This surface is where you go looking on purpose.

Queues

Guided fix queues for common health problems. Each queue is one class of problem with a way to fix it in place - you are not exporting to a spreadsheet and re-importing.

Work them in this order, because each fix makes the next queue smaller:

1. Records with no owner. Nothing routes to a record nobody owns. Approvals cannot find an approver, notifications reach nobody, and it is invisible in every "my records" view.
2. Contacts with no company. These break account-level reporting and are usually duplicates of someone already filed correctly.
3. Duplicates. Merge them. Every duplicate splits one relationship's history in two.

Records

Per-row triage. Where the queues handle a class of problem in bulk, this is for working through individual records that need a judgement call.

Imports

Import history and CRM connections. Every import that has run, and what happened. Check here immediately after any import from Apps and Import - it is where a partial failure shows itself.

After An Import

The standard sequence:

1. Run the import.
2. Open the Imports tab and confirm the row counts match what you expected.
3. Open Queues. Import creates owner and company gaps as a matter of course.
4. Work the no-owner queue first, then no-company, then duplicates.
5. Spot-check ten records by hand. Counts can be right while the content is wrong - fields landing in the wrong column pass every automated check.

Common Questions

How do I know if my data is healthy? The queue counts are the answer. Low and stable is healthy. Growing means something upstream is creating records without the fields that matter - usually an integration or a form.

Merging duplicates - which one survives? The merge flow shows you both and which values are kept. Check before confirming; the older record often has the better history but the newer one the better contact details.

A record has no owner and I do not know who it should be. Assign it to the manager of the team it belongs to rather than leaving it unowned. An imperfect owner routes; no owner does not.

Does this fix bad data automatically? No, and deliberately. It finds problems and makes fixing them quick. Deciding which duplicate is real is a judgement the platform should not make for you.