Our company operates five distinct business units in Oracle CX Cloud ocx-23c, each managing their own contact databases. We’re facing conflicting deduplication requirements that create a data quality versus compliance nightmare.
Business Unit A (Enterprise Sales) wants aggressive deduplication - merge any contacts with matching email addresses across all BUs to maintain a single customer view. Business Unit B (Regional Retail) needs to keep separate contact records even with duplicate emails because they track location-specific preferences and purchase history that shouldn’t merge.
Meanwhile, our compliance team requires complete audit trails showing when contacts were merged, who authorized it, and the ability to reverse merges if done incorrectly. The default Oracle CX deduplication rules are too rigid - they’re either global (affecting all BUs) or disabled entirely.
How are other multi-business-unit organizations handling tiered deduplication policies? We need a governance strategy that respects BU autonomy while preventing our database from becoming fragmented chaos. What policy configuration approaches have worked for balancing local control with enterprise data quality standards?
After managing multi-BU deduplication for three years across a global Oracle CX deployment, here’s the comprehensive governance strategy that actually works in practice:
Tiered Deduplication Framework:
Implement a three-tier matching model. Tier 1 (Exact Match): Email + Phone match triggers automatic flagging but not automatic merge - requires BU approval. Tier 2 (Fuzzy Match): Name similarity + address match creates merge suggestions reviewed by data stewards. Tier 3 (Cross-BU Match): When contacts match across BUs, escalate to enterprise data governance committee for review. This tiered approach balances automation with human oversight for complex cases.
Policy Configuration by Business Unit:
Create BU-specific governance policies in Setup > Data Governance > Business Unit Policies. For Enterprise Sales (aggressive merging): Set auto-merge threshold at 95% confidence for email matches within their BU, with cross-BU matches requiring approval. For Regional Retail (preserve local data): Disable auto-merge entirely, requiring manual review for all duplicates. Set matching rules to flag but not merge contacts with duplicate emails if they have different postal codes. This preserves location-specific customer records while preventing true duplicates.
Audit Trail Architecture:
Enable comprehensive audit logging for all merge operations: Setup > Audit Management > Merge Audit Policy. Configure to capture: merge initiator user ID, source and target record IDs, all field values before/after merge, business justification (required comment field), BU authorization approval chain. Store audit logs for 7 years per compliance requirements. Implement monthly audit reports showing merge activity by BU with anomaly detection for unusual patterns.
Business Unit Governance Model:
Establish a federated governance structure. Each BU appoints a Data Steward responsible for reviewing merge suggestions and approving cross-BU merges. Create an Enterprise Data Governance Committee (representatives from each BU plus compliance) that meets monthly to resolve conflicts and refine deduplication policies. Use Oracle CX’s workflow automation to route merge approvals: within-BU merges go to local steward, cross-BU merges escalate to committee.
Reversibility and Data Recovery:
Implement soft-merge architecture where merged contacts aren’t deleted but marked inactive with a “MergedInto” reference field pointing to the master record. Maintain all historical data in the inactive record. Create an “Unmerge” custom action that reactivates the merged contact and removes the master link. This allows complete reversibility if merges were incorrect. Document unmerge procedures in your governance policy and train BU data stewards on the process.
This strategy provides the autonomy each BU needs while maintaining enterprise data quality standards and complete audit compliance. The key is balancing automated efficiency with human governance oversight at decision points where business context matters.
The contact hierarchy approach sounds promising but I’m concerned about audit trail complexity. If we have a master record linked to multiple BU instances, how do we track which BU initiated a merge and maintain the ability to reverse it? Our compliance team needs to see the full lineage of merge decisions with timestamps and user attribution. Does the hierarchy model support that level of audit detail?
Jennifer’s approach works but creates another problem - data silos. We tried BU-specific rules and ended up with the same contact appearing 8 times across different units with no cross-BU visibility. Instead, implement a master data management layer with tiered deduplication. Create a “golden record” at the enterprise level that links to BU-specific contact instances. This preserves local data while maintaining enterprise visibility. Use Oracle CX’s Contact Hierarchy feature to establish parent-child relationships between enterprise and BU records.
The challenge here is that Oracle CX’s native deduplication wasn’t designed for complex multi-BU governance scenarios. You need a policy configuration framework that sits above the technical deduplication rules. Define a data governance policy document that specifies: 1) Which contact attributes trigger deduplication (email, phone, name+address), 2) BU-specific merge approval workflows, 3) Cross-BU merge escalation rules, 4) Audit and reversibility requirements. Then implement technical controls that enforce these policies. Without clear governance policies, any technical solution will create conflicts.