Hi Ankit,
Great question and one that comes up regularly - there's even a thread from 2023 on almost the same topic in this community (Organization Entity vs. Customer Entity). The short answer: yes, separating them is the right architectural call for your use case, and the D&B angle makes it especially clear-cut. Let me go through each of your questions directly.
Q1 - Has anyone done this split?
Yes, this pattern has been implemented across Reltio customers in financial services, insurance, and B2B contexts. The motivations are almost always the same three you named: D&B applicability, match/survivorship complexity, and governance. The migration is non-trivial but very doable with the right phasing.
Q2 - Major challenges
Relationships - the hardest part by far
All existing relationships reference entity instance URIs (entities/<oid>). When records are migrated to a new entity type, they get new entities/<oid> URIs. There is no automatic pointer-forwarding. Every relationship - including DnBHierarchy if you have D&B hierarchy relations today - needs to be exported, mapped to the new entity URIs, and re-created.
A specific thing to watch: if you already use D&B enrichment on the current Customer entity, D&B hierarchy behavior depends on your connector mapping and hierarchy policy. During your migration window, that can create a race condition between your relationship migration job and the live enrichment connector. Pause D&B enrichment during the relationship migration phase, or at a minimum set corporateLinkage mapping to inactive temporarily.
Data migration - crosswalks (including UI updates)
Beyond source-system loads, pay attention to crosswalks that were added through direct updates on the profile from the Reltio UI (manual steward changes, one-off fixes). These often don't exist in any upstream system and won't replay on a simple re-ingest. You'll need to inventory and explicitly migrate or recreate them on the new entity URIs.
To keep migration simpler, consider retaining the current Customer entity type for Organization records - delete Individual records from Customer and migrate only those to the new Individual entity type. That limits relationship and integration churn to the Individual split first, while downstream systems that already treat Customer as the org type see less disruption.
Crosswalks
Source systems feeding Customer need to be re-pointed to the new entity types where applicable. Crosswalk values themselves carry over cleanly on re-ingest - the complexity is at the source system level (what entity type path does each source write to?), UI/manual crosswalks as noted above, and at the enrichment connector level (D&B crosswalks are DUNS-keyed and will need to be re-associated to the Organization / Customer org URI).
Downstream integrations
Any event subscriptions, Snowflake/Salesforce connectors, or outbound pipelines keyed on Customer entity type events need cutover for Individual records. TThe Reltio event stream includes entity type in the event payload, so subscribers filtering or mapping on configuration/entityTypes/Customer will not pick up records moved to Individual. Audit your integration mappings before cutover.
Historical data migration
Entity IDs change for records moved to Individual. Downstream systems that stored Customer URIs as external keys will have broken references for those records. Build a URI mapping table (old → new) as a migration artifact, and plan how downstream consumers get updated. This also matters for audit trail continuity - if you have reporting or compliance requirements tied to historical entity URIs, factor that in.
Matching rules
Actually the most straightforward part once schema work is done. Separate entity types let you write purpose-specific rules without defensive exclusions: Organizations can use DUNS + Legal Name + Address; Individuals can use email + phone + name combinations. No risk of a person record false-positiving against an org record across types (Reltio does not match across different entity types). Do run the new match rules in lower environments first and validate recall/precision before loading production data.
Q3 - Is this best practice?
Yes, for long-term scalability and governance. A single entity type that mixes Individuals and Organizations creates compound complexity at every layer: match rules need exclusions, survivorship needs conditional logic, enrichment pipelines need BusinessFlag filters, and RBAC/data access policies become harder to reason about. Separate types give you clean separation of config, match groups, survivorship strategies, and enrichment pipelines.
Q4 - D&B on mixed-profile customer models specifically
This is where the case for splitting becomes especially strong. When D&B enrichment runs on a mixed entity type containing both Individuals and Organizations:
-
D&B match returns DUNS for org-shaped profiles only - person profiles either get no match or get false-positive org DUNS, polluting your Individual data with organization crosswalks.
-
D&B hierarchy relations (DnBHierarchy) can be added, removed, or replaced during enrichment depending on connector mapping and hierarchy policy - on a mixed model, you're exposing Individual profiles to this churn unnecessarily.
On a dedicated Organization entity type (or Customer retained for orgs only), the D&B connector is clean: DUNS-keyed match, enrichment runs only against org-shaped records, and hierarchy relations are stable.
If you can't do the full migration immediately - as an interim measure, you can add a BusinessFlag-based pre-filter in your D&B RIH recipe so enrichment only triggers on records where BusinessFlag = 1. This doesn't solve the match rule complexity, but it prevents D&B data from contaminating Individual profiles while you plan the migration. Treat it as a stopgap, not a long-term solution.
Recommended Phasing
-
L3 Configuration Update - Define the new schema (attributes, matching, and survivorship). If your model supports Individual ↔ Organization links, ensure both ends of the relationship types are updated.
-
Environment Validation - Start in Dev/QA. Extract current records, segment by BusinessFlag, and perform a bulk load into the new types to verify match and merge precision. Inventory UI/manual crosswalks.
-
Connector Governance - Halt D&B enrichment tasks temporarily while relationships are being migrated.
-
Relationship Cutover - Delete Individual records from Customer; migrate to Individual. Script the export and re-creation of relations. The old-to-new URI mapping table generated earlier is your critical asset here.
-
Integration Alignment - Update source connectors, outbound queues, and event filters for Individual; org-side Customer integrations largely unchanged if you retain Customer for organizations.
-
Enrichment Re-sync - Re-activate D&B on the Organization / Customer org type; the DUNS serves as your anchor for crosswalk stability.
-
Decommissioning - Maintain the original Customer type for org records during a parallel run so downstream systems can confirm data integrity before final cleanup of Individual data from legacy paths.
I can provide more detail on specific phases, especially regarding relationship scripts or the exact D&B re-enrollment logic.
References
------------------------------
Palli Somasekhar Reddy
------------------------------