Updated: Oct 14, 2020
After several years working exclusively with Zapier, one thing that surprised me when I began to transition to Integromat was the limitations of the "Sleep" module. The longest delay possible on Integromat is 300 seconds, so 5 minutes. For anyone used to work on Zapier this is something that is shocking.
On Zapier the so-called "Delay" app is really cool. The zap can be delayed until a specific time, for example the day before Black Friday (very useful for marketing application), or the zap can be delayed for a specific duration, for example 24 hours. Five minute delays are not very useful for real life workflows where the timing of an operation is critical.
In my search for a workaround I realized that Integromat scenario maximum execution time is 40 minutes. So hacked solutions that using a repeater in front of a sleep module were definitely out of the question. The only solution is to break the scenario in two. The first scenario basically create a task with a due date and store it somewhere (database, Integromat datastore, spreadsheet, ...). The second scenario basically search for due tasks and if a task due execute the rest of the automation.
So let's say we want to build an automation to send a text to new leads for our e-commerce store 5 days after they "abandoned" their cart with a 20% promo code.
The scenario 1 will be triggered when we have a new abandoned cart in our store and will create a new row in a dedicated data store with abandoned cart ID and the due date (now + 5 days).
The scenario 2 search every 15 minutes for due tasks. If a task due date is before now then the scenario runs, look for the abandoned cart details and send a text to the lead.
Not as simple as Zapier delay app but much more powerful. Why? First Zapier can "only" delay a task for a month so it can be a problem. But my favorite thing about this the setup described above is that the same datastore can be used for many different automations. Let's say for example we often need to delay the sending of a text for different workflows. In that case it is possible to use the same datastore and same scenario 2 to send all those texts by just adding some additional info in the datastore and some logic on the scenario 2.
This will make more sense with a concrete example below.
Create a text drip campaign on Trello using Integromat. Step by step instructions
To make it easier to process let's say we want to build a drip text campaign to keep the new users of our dating app engaged by sending them texts at the right time based on their app use to make sure they get the most of it. So we have 3 stages:
New Account created
Profile page completed
Went on 1st date
We want to send 3 texts to the user when they are on stage 1 to motivate them to complete their profile. One 2 hours after they sign up, one 24 hours after they sign up and another one 5 days after. Also we want to do something similar when they are on Stage 2. Importantly we need to verify the user stage before to text so the user is not asked to setup a profile if they already went on their first date.
1/ Trello Setup
I am not going to cover this in details but the idea here is to create one board for the drip campaign. Each stage has a corresponding list and the users are cards. The user card is created upon the user signing up and there is a custom field with the app user ID. The automation will be triggered when a card is moved to a new list (could be moved manually or from another automation triggered by in-app events).
2/ Integromat Scenario for Stage 1
For this fictional scenario I will need to create two scenario 1, one for each stage because I am using the built function in the Trello Integromat module to search cards that were added to a list and a list must be specified.
The scenario is pretty simple and does a few things. When a card is moved to the specified list the automation start. The next module use the card ID to get the card details. Here we are interested in getting the user ID. Then we have a router, the 1st branch look in the data store (in that specific example I am using a Google Sheet) for tasks that might be showing as "due" but that are no longer relevant. If such tasks exist I update the status to "void" in my status column.
The second branch actually add the tasks to the datastore/spreadsheet for future processing. In our example Text1 and Text2.
3/ Integromat scenario to send texts
This last scenario is very simple, every 15 minutes Integromat search for task in the spreadsheet that meet these two criteria:
Due date is early than "now"
Status is equal to "Due"
The rows that match both criteria are then sent to the next module that will send the text based on the row data. Once the text is sent the the last module update the row Status column to "Sent" so the text does not get sent over and over again every 15 minutes.
This scenario "Send Due Text" could be used across an organization for all scheduled texts. It is basically a Publish-Subscribe pattern and it can be very powerful if implemented well. One thing to keep in mind is that turning the scenario 1 that generate tasks will not stop the scheduled tasks, here texts, from being processed. So if a subscribe scenario (Send Text in our example) is pooled for several automations some safeguards should be put in place to void future tasks if the publishing scenario is turned off (Schedule Texts in our example).
The above scenario was a test set-up that I built a while back and in production I ended up using an Integromat data store instead because Integromat had issues returning searching rows by date. But the setup is exactly the same.