Reattribution alone does not fix attribution bugs in a CRM

After fixing a resolver bug that mis-attributed messages to the wrong person, just deploying the fix is not enough. The historical messages still carry the wrong person_id and will continue to display on the wrong page until you actively sweep them. Most CRMs have a reattribute-triage admin endpoint that re-runs the resolver over messages with NULL person_id, but that does not help if the bug attributed them to the wrong non-null person. The correct three-step sequence is: (1) deploy the resolver fix, (2) UNATTRIBUTE the polluted target — admin endpoint that sets person_id back to NULL and moves the message back to triage, scoped to the platforms or person you know were affected, (3) then run reattribute-triage which sweeps NULL rows with the new resolver logic. Step 2 is what people forget because the natural mental model is just-run-reattribute. In production a similar bug had 171 outbound WhatsApp messages mis-attributed to the user's own page. Without step 2 they would have stayed mis-attributed forever even with the fix deployed and the reattribute sweep run.