Reading view

What should survive when duplicate CRM accounts are merged?

Merging duplicate company records can clean up reporting while also collapsing details that were intentionally different: regional ownership, consent state, open opportunities, support history, external IDs, and field values from separate systems. What merge contract prevents silent data loss? I would expect a chosen survivor record, field-level precedence rules, a redirect from retired IDs, preserved source attribution, reassignment of related objects, and an audit record that can reconstruct the pre-merge state. How do you handle conflicting permissions and account hierarchies, downstream systems that still reference the losing ID, and the rare case where a merge must be reversed after new activity has already landed on the survivor?

submitted by /u/RocketSeven
[link] [comments]
  •  

What is a safe process for retiring unused CRM fields?

A field with few recent values may still feed an old report, integration, routing rule, permission check, or quarterly workflow. Deleting it too quickly can create a silent failure; keeping every field forever makes the schema harder to understand and maintain. What evidence do you require before retiring one? A workable process seems to need an owner, usage checks across automations and exports, a deprecation period, a replacement mapping when definitions changed, and a recoverable archive of old values. How do you handle fields that are technically populated but no longer trusted?

submitted by /u/RocketSeven
[link] [comments]
  •  
❌