Improving email timing in a Zapier loop for Webflow item creation
Hello, I am new’ish to Zapier and am trying to figure out how improve a Zapier Loop that ultimately creates an item in Webflow (with multiple locales) and then send an Email out with the newly created Webflow item’s URL.
The question itself is more around how to better time the email send out in Zapier.
Here is an excerpt of my process.
The way this works, is that I loop through 100 items at a time (as a way to handle rate limits across Webflow/Airtable/Sendgrid) and then pause a minute per loop.
During each loop, I create a Webflow item (and its locales) in drafted mode (A), and then send out an email (B), and then every 100 loops I trigger a Webflow site publish (C) which makes all the drafted items live.
The problem is that there can be a slight race condition where a user might instantly open their email and click the URL to the Webflow item before it has been published (which happens within a minute or so of email send-out currently). The nature of this task is pretty important so my goal is to ensure that the item is live before the email arrives.
I am trying to find ways to improve this without a bunch of complexity, and I think the route that interests me the most is if there is a way to just push the left branch (the emails) into a separate zap bucket that delays a minute or two and then send out? I.E. This other zap runs once every few minutes with all items pushed into it and loops through sending all the emails out - or something like that.
That way as the loop runs, it will push 100 or so of these emails into a delay outside of the loop (as if I delay in the loop it will drastically slow down the overall time to run this) while the Webflow publish option triggers and then when the emails send there should be no issues regarding the items not existing yet.
Things I already thought about:
Creating the Webflow items as Live items. This is not possible when using multiple locales - I think it is being worked on but not available yet. :’(
Moving all the emails to the right path. This would require me to store all the information for the emails in like a cache or Zapier table as they are looped and then loop through again on the Publish step to actually send out the emails… but unsure how much work or extra zap tasks it will cost in order to do this. I think I would have to add another loop too and am unsure if nested looping is supported.
Add a minute delay before each email is sent out - this would then make every loop take an entire minute (Zapier’s smallest delay time) and would drastically increase the overall run-time. Currently we only delay ONCE per loop at 100 iterations which is also when we trigger the Webflow publish.
Any suggestions or ideas appreciated! Thank you!
Page 1 / 1
Hi @Springthrough
Check which native Zap Apps count as 0 Tasks in Zap Runs:
TIP: You can set Delays for less than 1 minute. (e.g. .25 for ~15 seconds as it is not exacting)
It does not make sense why you have a Delay step as the last step in a Path as there are no Zap action steps to perform after the Delay step, so the Delay step is effectively doing nothing.
If you know a Zap Run that has 100 loop iterations takes say 15 seconds per loop iteration, then you could have the emails Delay (For) for 25 minutes before sending.
Hi @Troy Tessalone I shall look into the delay adjustment (for some reason I must have read that wrong) as well as what actions use 0 tasks.
Regarding the delay at the end, I have to pause 1 minute per loop regardless otherwise I will go over third party rate limits. That delay will trigger once every 100 loops to pause (the loop itself im assuming?). I figured i could put that at either the end or start of each iteration? The 100th iteration will also trigger a webflow publish too at the same time.
Or are you saying that the delay won't pause the loop, in which case if I delay the email step by 25 minutes the loop will continue on and just the email part will be delayed? If so, how could I force the full loop to pause once every 100 loops for rate limiting?
The final task will have 2500 or so loop iterations. With it triggering 100 loops per minute.
Thank you very much for the info so far!
Hi @Springthrough,
To manage looping and rate limits in Zapier, use a "Delay" step every 100 iterations by checking if the count is a multiple of 100 and inserting a pause. A "Filter" step can help identify when to trigger the delay. If an email step requires an independent delay, add a separate delay action before it. For rate-limited actions like Webflow publish, ensure they execute after the pause. Optimizing task usage minimizes unnecessary actions, improving efficiency.
Hi @JammerS, I am already doing everything you outlined above (you can see the filters and delays in my Zap’s screenshot at the end of each loop - if I understand how delays with Loops work correctly). I check for a multiple of 100 and if so I publish Webflow and also Delay the whole loop for 1 minute. The issue is that during these 100 loops emails are still sending out with each loop and if a user clicks an email within that 30-60 second window before Webflow has published the collection items they will get a 404.
I am trying to find a smart way to ensure the emails always go out, or delay, after publishing Webflow.
I am considering instead of sending emails each loop to just store/cache them in Zapier and then after the 100 loop iteration, and after Webflow publishes, to send them out but I am unsure if I can nest loops or if I need to trigger/call a different Zap to send out the emails?
You mentioned
If an email step requires an independent delay, add a separate delay action before it.
Can you elaborate what you mean? I assumed any delays within the loop will delay the entire loop and not just a single action - is there a way to specify if a delay affects the entire loop itself or just an iteration of it?
Thank you!
Hi @Springthrough,
In Zapier, delays within loops pause the entire iteration, which can interfere with workflows involving Webflow publishing and email sending. The challenge arises when emails are dispatched before Webflow completes publishing, leading to 404 errors. Storing email data during loop iterations and sending them only after publishing is a viable solution to prevent this. Using "Storage by Zapier," you can append email data to a list and trigger another Zap after Webflow finishes, ensuring emails go out at the correct time. Since nesting loops aren't possible in Zapier, triggering a separate Zap via "Zapier Manager" or a webhook can effectively handle the email-sending process independently. Another approach is structuring Zaps so delays only apply to the email step, keeping the loop uninterrupted. These methods help synchronize email dispatch with Webflow publishing and ensure a seamless workflow.
Please feel free to reach out if you have any further questions or need additional assistance.
Hi @JammerS, yea so what you are describing is essentially what I am asking and/or how best to do it - offload the email portion to be delayed separately from the parent looping task.
I was reading about sub-zaps and that seems like it could work well to handle the email portion. Do you know, if there is any way to not have a return step in a sub-zap - Google was implying this is possible but I cannot find out how? If I need to add a return step then I don’t think sub-zaps will work as if I put a delay in the sub-zap I think that impacts the parent zap - unless I can tell the parent to not wait for the sub-zap.
Or is this why you suggest using a Webhook? Are those not required to have return values?
It seems like sub-zaps are free tasks so I am just trying to explore less task-intensive options first.
Thanks!
Hi @Springthrough,
To manage email delays separately from a parent looping task in Zapier, consider using Sub-Zaps or Webhooks. Sub-Zaps enable modular workflows and can execute independently if configured without a return step, though any delays within them will pause the parent Zap. Webhooks, on the other hand, trigger separate processes without requiring a return value, allowing independent execution of tasks. Sub-Zaps can be more task-efficient when reused across multiple Zaps. If avoiding delays in the parent Zap is the goal, using a Webhook to trigger a separate Zap for email processing is recommended.
I hope this helps you decide the best approach for managing your email delays. Feel free to ask if you have further questions or need additional assistance.
Thank you @JammerS!
I ended up trying both routes, I am not sure if Zapier changed their rules or not, but it looks like you can no longer Save/Publish a sub-zap without a return step, a return steps seems to be a requirement now.. this will force the sub-zap to always be synchronous in execution.
However, the webhook route does work (can push those off as asynchronous executions), albeit you have to use tasks for this.
I think I am all set for now with things working.
Thank you!
Hi @Springthrough,
Thank you for sharing your experience and findings with the community. It's great to hear you've managed to get things working with the sub-zap and webhook routes.
Zapier's platform requires a return step in sub-zaps for reliable execution, making them synchronous. In contrast, webhooks enable asynchronous execution, allowing processes to continue without waiting for completion, though they do consume tasks. Both methods have distinct advantages depending on workflow needs.
If you have any further questions or need additional assistance, feel free to contact us. We're here to support you, and your insights are valuable to the community.
