Re: Add a delay step in a process

Steven_Aung · 05-12-2021 05:57 PM

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

Steven_Aung

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

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

Lusha_Wang1

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.

Steven_Aung

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?

Lusha_Wang1

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.

Steven_Aung

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

Zhifeng_Lin

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!

Steven_Aung

Sounds great. My ID is 540843.

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

Zhifeng_Lin

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!

Anthony_Nel

Please add me in ID 255473 Thanks

Zhifeng_Lin

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

Thanks!

Anthony_Nel

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>>

Zhifeng_Lin

Hi Anthony,

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

Thanks!

Anthony_Nel

“000:10:00”

Zhifeng_Lin

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!

Anthony_Nel

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

Zhifeng_Lin

got it.

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

Anthony_Nel

Welcome! thanks for the useful function

Zhifeng_Lin

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!

Anthony_Nel

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

e.g.

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

FREDY_ORTEGON

Please add me ID: 1949277 thanks

Zhifeng_Lin

Hi Fredy,

You have been added to the early access now.

Thanks!

FREDY_ORTEGON

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?

Zhifeng_Lin

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!

FREDY_ORTEGON

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

Koichi_Tsuji

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.

Zhifeng_Lin

Hi Koichi,

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

simply [Wait for a period] of time to delay the process, that is the use case discussed in this post.
[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”

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”
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!

Koichi_Tsuji

Thanks @Zhifeng_Lin

Good example. Now crystal clear!

Koichi_Tsuji

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?

Zhifeng_Lin

Hi Koichi, to further clarify:

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.
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.

Koichi_Tsuji

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.

Ryan_Mortimer

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!

Zhifeng_Lin

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

Thanks!

Ryan_Mortimer

Thank you very much!

I look forward to playing around with it!

jderechin

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

thanks in advance
Jacob

Zhifeng_Lin

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

Thanks!

jderechin

thank you so much