Hi Community,
I’m curious to learn how other organizations are handling multiple form submissions within a single session particularly when each submission is meant to trigger enrollment into separate workflows that include delays.
In our case, the second submission often fails to re-enroll the contact into the intended workflows because the first is still in a delay step. As a result, key fields may be missing, overwritten, or not updated correctly.
Would love to hear how you’re approaching this, any strategies or workarounds would be greatly appreciated.
Hi @ADurrani6,
That depends a bit on what the workflows are supposed to do. Can you please share a bit more context here?
One typical mistake users make is, for example, configuring a workflow that enrolls a contact, sends a confirmation email, then continues with delays and nurturing emails. As a best practice, this should be split in two workflows, on that only sends the confirmation email, another that sends the nurturing emails. As a result, the confirmation workflow can fire again and again if needed.
The same logic would apply to other automation – I can elaborate once you provide more detail. You want to execute the crucial steps in a workflow without delays, then hand over the record to other workflows.
Best regards
Hi @karstenkoehler,
Thanks for sharing your insights.
In our case, we’re updating and clearing specific fields during each submission so that any new values replace the old ones and correctly sync to the new deal or inquiry. This setup also works across multiple regions within the same account (e.g., UAE, US, etc.).
Here’s where the challenge comes in:
Let’s say a contact submits a lead via a UAE form, an inquiry is created and synced with Salesforce. We introduce a short delay in the workflow to ensure the inquiry creation and data mapping happen smoothly between the systems.
However, if the same contact submits another lead from a different region (e.g., the US) just a couple of minutes later, the system may not re-enroll them into the new workflow because they’re still stuck in the delay step of the previous one. As a result, fields like “latest source” don’t get updated properly, or some values may be missing altogether because we clear the fields on contacts right after copying over to the inquiry.
We’ve tried increasing and decreasing the delay time, but there’s no guaranteed buffer that consistently avoids this conflict. So managing multiple submissions within the same session especially when tied to time-sensitive workflows remains a challenge.
@ADurrani6 if there’s a contact-based workflow that creates a deal, you would have to design this workflow in a way that it does not include delays. If you think that’s not possible, could you please elaborate as to why exactly? Why is a delay needed before deal-creation?
Hi @ADurrani6,
We’ve seen similar issues with multiple form submissions in a short time frame especially when workflows have delays and field resets involved. It sounds like your setup is super thoughtful already, but the main issue here is that HubSpot doesn’t handle re-enrollment well if the contact is still “stuck” in the middle of a workflow, especially during a delay.
Here are a few things that have worked for us or others in similar situations:
Instead of relying only on form submissions to re-enroll people into workflows, try using static lists. For example:
- When someone submits a UAE form, add them to a “Submitted UAE Form” list.
- Use list membership as your workflow trigger instead of the form directly.
- After the contact is enrolled, remove them from the list so they can be re-added next time.
It’s a little hacky, but this can let the same contact trigger a different workflow even if they’re mid-way through another one.
One trick we’ve used is to create temporary fields to “hold” the new values from a second submission, rather than overwriting live fields immediately. Once the first workflow is done, another workflow can cleanly copy over the “holding” values. It adds a layer of complexity but avoids the race conditions you’re seeing.
@Wesimplifi_ I would disagree here, list membership typically takes longer than workflow enrollment, adds more delay to the process and thus risk of blocking re-enrollment.
Thanks for jumping in and I agree that it’s not always the fastest trigger compared to direct form submissions or property changes.
That said, in our specific use case, we’ve found list-based enrollment can still be useful if we build in a small buffer or combine it with other conditions (like time-stamped custom properties) to ensure re-enrollment isn’t missed. It’s not perfect, and we’ve definitely seen cases where list updates lag but compared to purely relying on direct form-based workflows (which can get blocked by delays), it gives us a bit more control across multi-region flows.
It really depends on the complexity of the setup and the timing sensitivity we’re still exploring the best middle ground that avoids data conflicts without relying solely on lightning-fast triggers.