Anyone else seeing duplicate email loops after the latest platform update? My lead follow-up agent is now sending the same "welcome" email 3-4 times to new contacts, which is a great way to get marked as spam.
I’m using a standard sequence trigger: when a new lead form is submitted, the agent pulls the data and sends email one. The workflow logic hasn’t changed, but the behavior has. I’ve checked:
* The trigger source (form submission) is not firing multiple times. The lead is created once in my CRM.
* The agent’s condition to check if the welcome email was already sent appears to be failing. It’s supposed to look for a specific tag added after sending.
* There’s no delay or waiting step between the send action and the tag application, so it should be immediate.
This points to the platform’s internal state tracking being off. If the agent doesn’t correctly register that it performed the “send and tag” step, it will just run it again on the next check.
Has anyone dissected this yet? I need to know if it’s:
1. A bug in the agent’s memory/state logic for this specific action.
2. A broader issue with how the platform now handles asynchronous actions (like email sends) before marking a step as complete.
3. Something changed in how tags are written and read back, causing a race condition.
Temporary fix is to add an artificial pause after the send action, but that’s a band-aid. Looking for a root cause analysis.
-- CRM Surfer
Your CRM is lying to you.
Ah, the classic "state management is someone else's problem" assumption. You've checked your CRM, your tags, your workflow... but have you considered the cheaper, more annoying option? This screams a classic vendor move: they "optimized" their action queue without updating the event acknowledgment logic.
Your bet about asynchronous actions is warm, but I think it's more specific. That "send and tag" step you mentioned - if the platform now batches API calls or uses a faster, eventually-consistent queue for email dispatch, the agent's own "tag application" step might fire before the platform's internal "email sent" flag is committed. So the agent thinks it's done, but its own memory check fails because the state is split. The fix is probably to insert an artificial delay, which is hilarious because you're paying for automation to then add manual delays.
Has anyone tried wrapping the send action in a pointless "log this to a custom field" step first? Sometimes adding a synchronous write operation forces the queue order back into alignment. It's a band-aid, but it works while we wait for them to admit the regression.
Price ≠ value.
I'm hitting this too, but with webhook-triggered onboarding sequences. Your point about the platform's internal state tracking is interesting. I was blaming my own workflow logic.
Did you try adding a manual 2-3 second delay before the tag step as a test? I'm scared to try because it feels like a hack, but user893's point about async queues seems plausible. It would explain why the tag check fails immediately after sending.
If it's a vendor update issue, is there an official changelog or status page where we can check? I'm new to this platform and not sure where to look.