Delay / Pause Module

I would love a Delay or Pause module, similar to what Zapier does natively.

I have a system that uploads a Google Meet link to a user at, for instance 10pm, but then at 10:50pm it must delete the link.

I’ve seen the workarounds such as create a drip campaign etc. but it doesn’t work for my needs.

All of these seem to require watching a data store for a specific timestamp, but of course then I need to create a scenario that polls that data store every 5 minutes.

I would love the possibility to just input an x minute pause in between modules, and to be honest it’s the only thing keeping me from switching over from Zapier completely.

Yeah it’s certainly a drawback. I’ve just built out my own small database/api to reduce operations but it’s not for everyone.

And easy (and cheap) tool to use for this would be Cronhooks.io. I’ve used it with pretty good success!

1 Like

Interesting idea, I could just set up specific webhooks to fire at those timed intervals.

Thanks for the suggestion, it’s a great one.

Would still prefer to not have to use a workaround like this though - I understand there may be runtime limitations for each scenario, but if Zapier can do it I’m sure Make can as well

Yeah frustrating but at least it is a workaround. Imo it makes up for Zapier’s downsides and the money spent on Cronhooks + Make is much lower than Zapier haha

Right, agreed. This is my first month using Make after a decade with Zapier, and already I’m finding some significant improvements (not to mention the cost).

There is a sleep module. Can that work for you?

2 Likes

Thanks for your input. The sleep module is limited to 5 minutes, I believe, and I need 50 minutes of delay.

Put 10 of them back to back. To be sure max scenario execution is 40 minutes.

1 Like

Would going off an Airtable trigger be good for you. You can sort of log through Airtable and do it that way. Watch this video and see if it would be worth it for you to implement this stuff over into Make?

Hey @AnthonyatXRay thanks for the info and video - it’s certainly possible with Airtable or by using something like Google Sheets as a data store that’s polled every 15 m, but I’d like to avoid these kinds of workarounds as my clients expect simplicity with the automations I create for them.

Right now I’m considering:
Scenario 1:

  1. webhook trigger

  2. 25m of sleep (5 back-to-back sleep modules)

  3. send to Scenario 2 via webhook

Scenario 2:

  1. webhook trigger

  2. 25m of sleep (5 back-to-back sleep modules)

  3. subsequent modules

If anyone in the future is reading this, I did find success with the aforementioned workaround.

Using this I was able to get a 40m delay with my scenario.

So a scenario triggered at 10AM could be delayed until 10:40AM with this workaround:

Scenario 1:

  1. webhook trigger
  2. sleep module set to 300 seconds
  3. sleep module set to 300 seconds
  4. sleep module set to 300 seconds
  5. sleep module set to 300 seconds
  6. send to Scenario 2 via webhook

Scenario 2:

  1. webhook trigger
  2. sleep module set to 300 seconds
  3. sleep module set to 300 seconds
  4. sleep module set to 300 seconds
  5. sleep module set to 300 seconds
  6. subsequent modules
1 Like

This seems like 40 minutes total of delay, but I guess you could add yet another scenario and keep chaining them.

edited for clarity. Thanks for catching my math mistake.

It seems like a waste of operations to have to run multiple sleep modules. I wonder if anyone at Make can explain why sleep is limited to 300 seconds?

I haven’t really looked into the Make API but I think there’s a way to turn on a module, and to set it’s automatic start time? You could put everything after your sleep into it’s own separate scenario, Then you’d just have to set it’s start time and turn it on? Can scenarios turn themselves off with the API?

Still a lot of work when we already have the sleep module that could sleep longer.

I would also love to have a “Sleep Until” module that either starts a watch module, or has a loop that you can add a Sleep + whatever check you need to do.

3 Likes

Max has the solution… it works really well (his YT channel is one the most useful channels on Make)

3 Likes

Totally agree, it seems like a minor change and will prevent these hacky workarounds.

Thank you for sharing this, it is a very useful resource.

1 Like

This approach using the datastore as a queue to manage is very clever. I wonder how it will operate at scale in terms of operations used since you may have quite a bit of queued records to manage and if you get a large amount of records in a 15 minute time span you may have an issue with processing all those records at once. I guess you could check more often as well if you want to process smaller pieces of data.

2 Likes

Agreed @alex.newpath - the issue I have with it is that it’s an inelegant solution - I may have 20 entries at the same timestamp that would need to be processed, so while it may work for one bundle at a time, it doesn’t work for my use case. I’d need to prepend each timestamp with a unique identifier to make sure the correct ones are processed by subsequent steps, and it would be a huge headache.

Again, it’d be so much simpler if, y’know, I could just define the sleep module as X minutes, but perhaps that’ll come in a future update.

1 Like

Is there already any improvement for a longer time period to pause/delay the scenario?