An automation created a duplicate CRM record while I was manually fixing the same record #3
crowcreation
started this conversation in
Drift Incidents
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
A prospect who I'd previously marked as "closed-lost" replied to an old email. I saw the reply and started manually reopening the deal in our CRM - updating the stage, clearing the close reason, pushing the close date, adding a note.
Meanwhile, an automated email-processing pipeline also saw the same reply. It created a brand new deal for the same prospect, updated the routing config to point at the new deal ID, and logged a touch event.
Result: two deals for the same prospect, each with partial state. My manual updates went to the old deal. The automation's updates went to the new one. The routing config pointed at the new deal, so future automated touches would go there. But my notes and stage updates were on the old deal, so the next time I checked the CRM manually, I'd see stale information.
I caught it because I ran a defensive lookup after my writes and the deal stage didn't match what I'd just set. Traced it to the duplicate.
Drift mode: State staleness (two writers, neither checking the other's work)
What broke: No deduplication check. The automation's "create deal on first touch" logic didn't check whether a deal already existed for this contact (even a closed one). My manual workflow didn't check whether the automation had already acted. Neither process knew the other was running.
What changed: Two rules. (1) The automation now checks for existing deals on the contact before creating a new one - if one exists within 60 days (any stage), it associates the engagement to the existing record instead. (2) The manual checkin workflow now queries all deals on the contact first, flagging any that were created since the last touch in the routing config.
Pattern: When an automated process and a manual process can both respond to the same external event, one of them needs to yield. In practice, the automation should check for recent manual intervention, and the manual workflow should check for recent automated intervention. Neither should assume it's the first responder.
All reactions