CRM shows one email for a taxpayer while billing shows a different email for the same matched person. What should survivorship design do?
Select an answer to reveal the explanation.
Short Explanation
When two systems argue about an email, you need a house rule—not a shrug. Survivorship is that house rule: which source wins for which field, and under what conditions. Coin flips and 'longer is better' are not governance.
Full Explanation
When CRM shows one email and billing shows another for the same matched taxpayer, survivorship design should choose the surviving email using explicit rules such as source trust, recency, or attribute-level priority—not an arbitrary coin flip. Transparent civic rules beat silent randomness when residents complain about contact failures. Keeping both emails as separate golden records so matching never collapses the person fails by refusing to master the party and defeating the golden-record goal. Always preferring the longer email string fails as a nonsensical proxy for accuracy. Discarding email from the golden record whenever sources disagree fails by throwing away needed contact data instead of applying governed choice. Exam caveat: survivorship is rule-driven attribute resolution after match—not random, not “keep everything as separate people.” Operational check: publish attribute-level trust/recency rules for email, test on known conflicts, and log which source won and why for audit. Review disputed survivorship outcomes with tax and customer-service stewards in the municipal MDM operating forum. Keep verification evidence with the municipal runbook so audits can prove the chosen control was applied as designed and that rejected alternatives would have left city services exposed to the failure modes described above.