What’s Fixed
Behind the scenes, a contact is recorded as belonging to a pond in two places: the contact’s own pond assignment, and a separate row noting it was added to that pond. That second row is only cleared when a lead is claimed — so reassigning a lead to an agent, moving it to a different pond, running a bulk assignment or letting an assignment rule route it all leave the older record in place.
Automation conditions on the “pond” field read that leftover record, so an automation targeting a pond kept firing on contacts that had left it, sometimes long after another agent had taken them over. Smart Lists never had this problem — they always read the contact’s current pond assignment — so the same criteria could produce different sets of people in a Smart List and in an automation.
Bug Fixes
- Automation conditions on “pond” (and “assigned to pond”) now match only contacts currently assigned to that pond, exactly like the equivalent Smart List filter. If you have an automation targeting a pond, it will now stop running on leads that have been reassigned or claimed out of it — this may reduce how many contacts it enrolls.
- Fixed a case where reassigning a pond lead from the older contact page could erase the record of leads previously claimed from that pond, which the “claimed from pond” reporting fields depend on.
Pond lead counts, pond access and Smart Lists already read the contact’s current pond assignment and are unchanged.