Debugging mapping failures — Data 360 how-to
A DMO attribute lands blank, or wrong, or a record won't unify. The diagnostic flow is the same every time — walk from the DLO up to the DMO and find the layer where the value breaks. The mapping debugging playbook.
A value isn't where it should be. A DMO attribute is blank for every record. A date won't parse. A field shows the right data for some records and garbage for others. Or identity resolution won't unify two records you know are the same person. Mapping failures are silent — nothing errors, the value is just wrong downstream — so the diagnostic is always the same: walk from the raw DLO up to the DMO and find the layer where the value breaks.
The layers
[ Source system field ]
↓ ingestion (Data Stream)
[ DLO field — raw, as delivered ]
↓ mapping
[ DMO attribute — harmonized ]
↓ identity resolution
[ Unified profile ]Each arrow is a place a value can break. Check them in order; the first one that's wrong owns the bug.
Step 1 — Is the value correct in the DLO?
Before blaming the mapping, confirm the raw data actually arrived. Inspect the DLO — does the source field hold the value you expect, for the records you expect?
- Blank in the DLO too — the bug is upstream, in ingestion or the source. The mapping is innocent; check the Data Stream and the source query. (See DLOs.)
- Correct in the DLO — the data arrived; the bug is at the mapping layer or above. Continue.
Step 2 — Is the field mapped, and to the right attribute?
Open the mapping for the DLO to DMO. For the attribute that's wrong:
- Unmapped — that's the blank. A required attribute left unmapped produces blanks with no warning. Map it. (See mapping.)
- Mapped to the wrong attribute — the classic
statelanding incountry. The value is going somewhere; it's just not where you're reading it. Re-point the mapping to the attribute whose meaning matches.
Step 3 — Is it a type mismatch?
If the field is mapped correctly but the value is garbage or missing for some records:
- A date stored as text in the source mapped to a date attribute either fails to parse or coerces unpredictably — the records with an unexpected format are the ones that break.
- A number with formatting (thousands separators, currency symbols) mapped to a numeric attribute drops or nulls.
The fix is to normalize at the mapping layer, or correct the type, so the DMO attribute receives what it expects.
Step 4 — Is the primary key making records collide or split?
If whole records are missing or doubled rather than individual attributes being wrong:
- A non-unique primary key collapses distinct records into one — rows disappear.
- A key that changed between runs makes the same record land as two.
Confirm the key uniquely and stably identifies a row. (See relationships & keys.)
Step 5 — Is identity resolution the layer that's wrong?
If the attribute is right in the DMO but the unified profile is wrong — two people merged, or one person split:
- Two customers merged — match rules are too loose. The unified profile shows one person with both customers' data.
- One customer split — match rules are too strict, or the matching attribute (email, phone) is inconsistent across sources.
Identity resolution is a layer above mapping; a clean mapping can still produce a wrong profile if the match rules are wrong.
Common causes ranked by frequency
| Symptom | Likely layer | Where to look | |---|---|---| | One attribute blank for all records | Mapping — unmapped | The DLO to DMO field mapping | | One attribute wrong for all records | Mapping — wrong attribute | The mapping; match meaning, not name | | Attribute wrong for some records | Type mismatch | Source format variance; normalize on map | | Whole records missing or doubled | Primary key | Key uniqueness and stability | | Two customers as one, or one as two | Identity resolution | Match and reconciliation rules | | Value blank in the DLO too | Ingestion / source | Data Stream and source query |
Related
- Mapping DLOs to DMOs — the step this page debugs
- Data Lake Objects (DLOs) — where you confirm the raw value
- Data Model Objects (DMOs) — the harmonized target
- Relationships & keys — primary key collisions and splits
- Data 360 (formerly Data Cloud) architecture gotchas — the model decisions behind these failures
- Style Guide — the discipline that prevents this debug session from happening twice