Add a delay step in a process

It will be nice to have a delay step within a process.

For my use case, after creating a file via a task, it takes few seconds before we can access to the file. I like to put some delay, and then proceed other steps.

Please also put “Automation”, “Task”, “Process” tags for topic creations.

Thanks

0 36 2,429
36 REPLIES 36

I am not sure how frequent AppSheet will check for the condition in “Wait for a condition” step. Can anyone provide that information?
3X_8_a_8a87924cfa489cacbc2ae4dc0eafa343bfa53850.png

I can record a timestamp in a previous step. And then, use that timestamp in a “Wait for a condition” step to delay for next step but I like to know how frequent the condition will be check. Will it be checked indefinitely until the condition is met?

Thanks

Hi Steven, when a data change happens, and the wait step will be triggered immediately. We are not using polling mechanism to query for condition result.

Hm, in that case, the description for the condition checker is misleading. It said “Wait until this condition is true”.

So is “Wait for a condition” the same as using “Branch on a condition → Yes” flow?

Hi Steven, sorry for not being clear. “wait step” and “branch on a condition” is different. For wait step, assume the condition is column [Approve] = true, and right now the [Approve] = false, then it will keep waiting. But we don’t have any polling mechanism. Once [Approve] because true, then process will keep executing immediately.

Got it. Thanks. So we will need some kind of a delay mechanism in a process

Hi Steven,

We are planning to release a new feature on the wait step where you can simply wait a period of time.

The new Wait step type allows the process to pause execution and before resuming:

  • [Wait for a condition] to evaluate to TRUE or a timeout period to be reached
    And here you can add steps in case the timeout period has be reached
  • [Wait for a period of time] (min allowed is 10 mins and max allowed is 30 days)

Note: Process execution will not resume at the exact time that time period is met. There may be a delay of up to 10 minutes. Therefore, the Wait step does not support use cases where accurate timing is required.

Would you be interested in getting early access? If yes, just let me know your appsheet user id.

Thanks!

Sounds great. My ID is 540843.

Is there any chance that the minimum allowed time can be lower when this go live?

Hi Steven,

You user account has been added to the rollout for the new feature now.
As for lowering the minimum period, the Wait Step is targeting human-in-the-loop interactions for long running processes, so 10 minutes would be a reasonable minimum interval and we will stick with this in the initial release of the feature.

Thanks!

Please add me in ID 255473 Thanks

Hi Anthony, you have been added to the rollout for the new wait step feature.

Thanks!

Thanks - found a small issue with it - I sent a Notification after a Wait step and it ignored my app’s time zone (UTC +2) - it used UTC when formatting the time using <<_NOW>>

Hi Anthony,

Can you share the expression you used for the “Period” field?

Thanks!

“000:10:00”

With this static period expression, the process will be paused for 10 minutes (or another data change event that satisfies the “condition” field) once it hits the wait step.

So you meant in the Notification body, you used <<_NOW>>, which should honor your app’s time zone, but instead generated a UTC timestamp?

Thanks!

yes that’s the issue. - the exact same notification formats correctly when i remove the delay step

got it.

Thanks for the detailed explanation!
Will look into fixing the issue.

Welcome! thanks for the useful function

Hi Anthony,

Upon further investigation, this is an expected behavior/limitation given the current implementation.
The timezone & locale information are inherent from the request that is sent from your device (including browser) that is running the app.
But for waking up a suspended process after the delay, the request does NOT come from your device anymore. It’s from another google cloud service and it does not know about the timezone of your device. As a result, the default timezone is used, which is UTC.

We will ensure this limitation/behavior is well documented when we release this version of the wait step feature.

Thanks!

My workaround : add my locale time offset of +2 hours:

e.g.

Task Report Sent at : <<NOW() + “002:00:00”>>

Please add me ID: 1949277 thanks

Hi Fredy,

You have been added to the early access now.

Thanks!

Thanks for adding @Steven_Aung , I would like to corroborate the operation of the wait condition action, if when the bot is executed the condition is met, the bot continues the flow? or after 10 minutes it resumes again ?. It happens to me that when the bot is executed, the condition is already being met and the bot continues, a behavior that I think is great. But if I wanted to know if after time it runs again?

Hi @FREDY_ORTEGON the short answer is No, it won’t run again

There could be 3 scenarios if you configure a wait step to have both a condition and a period (say 10 minutes in the screenshot above):

  • when you first enter the wait step, if the condition is already met, it will continue the flow without waiting and won’t run again

When you first enter the wait step, if the condition is NOT met, the process will go to “sleep” until –

  • within 10 minutes, another UPDATE happens to the same row that triggers the bot initially, and that updated row now satisfies the condition, the process will resume the flow
  • after 10 minutes, the process will resume the flow

Hope this explains.
Thanks!

It has been clear to me, thank you for your answer!!!

Hi @Zhifeng_Lin

On the screenshot I see elsewhere, there is “timeout” step immediately after the Wait for a period of time step. Why and when technically this timeout will happen? Could you elabrate the case where timeout would happen?

Thank you.

Hi Koichi,

The new wait step is to have two different modes of operation –

  1. simply [Wait for a period] of time to delay the process, that is the use case discussed in this post.
  2. [Wait for a condition] to evaluate to TRUE or a custom timeout period to be reached
    And here you can add steps in case the timeout period has been reached

With the use case shown in the screenshot above, the wait step is to
"Wait for approval input for 10 minutes; if there is no decision after 10 minutes, send an email and auto reject the purchase"
Assuming we have a simple “purchase approval” table with the following columns

  • | PurchaseId | product | cost | approved |

Initially, a row [“ABC”, “vegetables”, “$100”, “”] (approved column being empty) triggers the bot and takes the process into “sleep”

  1. if within 10 minutes, an table update happens to the same row and set the [approved] column to “Yes”, the process will resume and return “Yes”
  2. After 10 minutes and there isn’t any table update to the same row to set the [approved] column yet, the process will be considered as “Time out”, so it will wake up entering the “Time out” branch and first send an email, then auto reject (a data action that sets [approved] to “No”), then finally return “No”

Hope the above example clarifies.

Thanks!

Thanks @Zhifeng_Lin

Good example. Now crystal clear!

Sorry, just one more question.

Now I understand we are going to able to add “Period” for wait for a condition step, in addition to pure Wait for a period of time step.

On both case, what is going to happen after 30 days?

Let me assume I set the wait for a condition step, but I leave the “period” field blank. Then without further interaction to the app, 30 days elapsed.

What is going to happen in this case? Assuming we have further steps after this wait for a condition of the step. In this case, BOT will die out without doing the rest of process, right?

To the contrary, if we set the period as 30 days, then without data changes, timeout to be triggered. In case we set NULL for this timeout blanch, I belive both setting will work equally.

Make sense?

Hi Koichi, to further clarify:

  1. With “Wait for a period of time” selected, you are supposed to specify a period (between 10 minutes and 30 days), and the process will always wake up and resume the remaining flow after the specified period of time. And leaving it blank will default to 30 days. We should probably throw an error on “Save” to make sure a valid period is entered.

  2. With “Wait for a condition”, there is now a “Custom timeout” checkbox
    a. if “Custom timeout” is not selected (equivalent to having “period” blank), by default, after 30 days, the process is considered “timeout” and “die” without doing the rest of the process (this is the “old” wait step behavior).
    b. if “Custom timeout” is selected, you are supposed to provide a period again. Leaving it blank will default to 30 days. (We should probably throw an error if period is empty). And the process will not “die” but always resume after the specified period of time.

    • if the “timeout branch” is occupied with more steps, those steps will be executed first and then the remaining steps in the “main” branch. But you do have the option of “killing” the process without executing the remaining steps in the “main” branch by putting a return-step at the end of the “timeout branch” (that is what a return-step will do, which is to terminate & finish the process).
    • if the “timeout branch” does not have any steps, the process will resume and start executing the remaining steps in the “main” branch.

Yes, that s for sure. Better to thorw the error when the app creator leave the filed blank.

This is also tricky part.

To avoid any possible confusion like this to occur, I would suggest we see error message in case we leave the field blank all the time. Thank you anyway.

Sorry to jump on the bandwagon here, but I would absolutely love to be added to early access for this.

I have A LOT of use cases for this!

App ID: 286964

This would be an excellent feature, especially seeing as many automation platforms use this regularly and it is what a lot of large scale clients expect on that front.

I’m very excited to see what the future brings!

Hi @Ryan_Mortimer
I have added your account to the rollout of the new feature.

Thanks!

Thank you very much!

I look forward to playing around with it!

HI @Zhifeng_Lin please add me to the test the behavior please, my id: 4620920.

thanks in advance
Jacob

Hi @jderechin ,
This is now available to all AppSheet users, please see this announcement –

Thanks!

thank you so much

Top Labels in this Space