A setting that stored correctly, read back correctly, and was never in force

The automation that raises sales process tasks had raised the same one twice, seconds apart. Each of its eighteen checks looks for an existing task and then creates one if it finds none, which is a question rather than a rule, and two runs happening at once both pass it. The run history settled it. […]

In this series · Part 21 of 22

On this page

Free Revenue Lifecycle Assessment

Connect with Marissa Wright to receive a free Revenue Lifecycle Assessment Report on your own business.

Book a consult →

The automation that raises sales process tasks had raised the same one twice, seconds apart. Each of its eighteen checks looks for an existing task and then creates one if it finds none, which is a question rather than a rule, and two runs happening at once both pass it.

  • The run history settled it. Two runs that overlapped produced both duplicate pairs, and a third run seconds later, which overlapped nothing, produced exactly one task. The gap that had looked like a coincidence was the gap that let the earlier runs finish.
  • The obvious remedy is to make the automation run one at a time. That setting was written into the live definition, read back correctly, and survived switching the automation off and on. Runs kept overlapping anyway. Every check except the one that looked at the outcome would have reported this as done.
  • A later test carried the more useful finding. Seven genuinely overlapping runs produced seven tasks and no duplicates at all, so overlapping is necessary but not sufficient, and the fault is intermittent rather than systematic. That argued against building an automation that deletes tasks.
  • What shipped instead is a report. It reads only, follows every page rather than the first, and separates a real collision from ordinary test leftovers by whether the copies appeared in the same second. Its first run found an open pair that nobody had noticed.