Can someone describe a situation where you would u...

Marc_Dillon · 04-05-2022 12:30 PM

Can someone describe a situation where you would use a 'Wait' Step in a Bot? I'm struggling to come up with any theoretical situation that would benefit from a Wait Step. Either 'Wait for condition' or 'Wait for a period of time'. Specifically, what benefit does the Wait Step provide that could not be achieved without using it, or without setting up other Bots?

My thoughts so far:

1. Instead of a "wait for condition", why not just build another Bot with that other condition on it?

2. Instead of a "wait for period of time", why not just change the current Bot's Event condition to trigger on some later data change? Or if there is no later data change, then what is the use of the wait?

@WillowMobileSysI saw you just post a BUG post about Wait Steps, so maybe you can respond?

SkrOYC

Maybe the wait may help to just "listen" to a certain condition once.

For example, send a report but wait until all of the children are [Status]="OK"

Marc_Dillon

Can you elaborate?

Why wouldn't I just build a Bot that triggers on child data changes and also checks that all children of the same parent have [status]="OK".

SkrOYC

Because you would need to trigger the bot when all of the childrens are OK for it to work while with the wait condition you could trigger it before and just wait.

Idk if this would work but a common problem is when the children are PartOf the parent.

I guess that you could allow the creation of the children from it's parent form leaving a Status column out of the form that can be changed with a button.

Then a bot of Adds only is executed when the parent is created but it waits untill the children are OK, so:

It doesn't come out without it's children on the template, generaly added via Start:[Related]
You don't need to execute the bot via some action that you have to remember to do so after your children are OK
You don't have a bot checking to both the parent and it's children that could be triggered again if the condition keeps beign true

I think that there are some things that could be done via bots without wait, but wait have the posibility to make it easier.

PS: I haven't had the need for any wait for the moment so this is theoretical

Marc_Dillon

That's a good thought!

But I see a major flaw to it. How would the Bot know when the user is done entering the children? Without any other user intervention (like a data change Action), there'd be no way to meet the condition without it also just being met immediately (before there are any children at all).

This is exactly why I ask the question, because every situation I think of that might benefit from the Wait, I then also see reasons why it just wouldn't work.

SkrOYC

I mean, it wouldn't know when all of the children are added (unless there is some way to give specifics about it like Count([Related])=6) but it'll know if all of the children are OK.

The thing that I don't know for sure if a wait keeps track of new records (it may sound silly, but Idk) or just expects changes to the records that were already made when the bot triggered

Marc_Dillon

"but it'll know if all of the children are OK."

What workflow are you envisioning for this status then?

If the status starts out as OK, then after the very first child is added, then all children are OK, and the Wait condition would be met, regardless if the user wanted to add more children or not.

But if the status needs to be changed at some point after the children are added, then you're still needing to run another data change Action to make that change, and which point it seems pointless to use the Wait condition.

"The thing that I don't know for sure if a wait keeps track of new records (it may sound silly, but Idk) or just expects changes to the records that were already made when the bot triggered"

Yes I'm also not sure about what state of the app the "waiting" Bot is expected to be in.

Since the documentation describes the 'wait for a period of time' as not being exact, but may be delayed by 5-10 minutes, I assume this means that the "waiting" bot is polling (or "syncing"), the new data every 5-10 minutes. In comparison to that, I'd expect any new data changes would be sent immediately to any "waiting for condition" Bots to check the condition again, with a newest data state.

Just my guesses though.

WillowMobileSys

First, the bug I posted is likely not directly related to a Wait. I just noticed that in the logs the Condition from the Wait was being logged rather than the Condition from the Bot Event. This may just be a logging problem.

Yes, I agree. I don't like waits.

Internally, within the app, I don't believe there is any need, any longer, to use Waits. See my comments below on recent automation update.

However, if the app expects information from an external service, I think there are uses cases where a Wait may be the simplest course of action.

---------------------------------------------------------------------

The reason I had been dealing with the Wait was simply because I had forgotten of the recent capability to trigger a Bot from a Bot.

I had been building enhanced automation using the API to speed things up. I found that going to a step that depends on the previous one, it may be the previous rows are not yet available by time the second step kicks off and would then fail with "No rows present". I inserted a Wait w/Condition to fix the problem.

I later realized about the "Bot triggering a Bot" and actually implemented a portion of the automation using that when I encountered extreme difficulty attempting to insert a second Wait. I now need to go back and use the same capability to remove the original Wait. Just haven't done it yet.

Without the "Bot triggering a Bot" feature, I would have had to rely on Wait's to achieve my goal of a speedier automation process.

Marc_Dillon

" I just noticed that the in the logs the Condition from the Wait was being logged rather than the Condition from the Bot Event. "

Ahh, interesting. This lends credence to something I just replied to Oscar with:

" I'd expect any new data changes would be sent immediately to any "waiting for condition" Bots to check the condition again, with a newest data state."

It's almost like the Appsheet system itself is creating an entirely new "internal" Bot, everytime there is an ongoing 'wait for condition' step, that is a sub-set of your configured Process.

----------

"if the app expects information from an external service, I think there are uses cases where a Wait may be the simplest course of action."

Hmmm. That may be a viable situation for a wait. I'll have to consider it more. For now my brain is getting tired...

dbaum

@WillowMobileSys wrote:

the app expects information from an external service

I've been working on an app feature that depends on the app detecting when information has been received from an external service. I know there are (and I have used) other techniques, but it occurred to me to experiment with Wait on a condition. When I was unsuccessful, I came across this comment.

Did @WillowMobileSys or @Marc_Dillon end up finding a way to use Wait on a condition in this scenario?

In my testing, Wait on a condition does not detect a data change made directly in the spreadsheet data source--even when the worksheet has AppSheet external eventing enabled. For example, I created an automation triggered by a row add, included a Wait condition of ISNOTBLANK([Column]), and then manually populated that column in the worksheet. The automation always routes through the Wait step's timeout branch.

WillowMobileSys

I'm sorry. I have no helpful information to add.

Joseph_Seddik

I haven't used wait in bots, so I'll be generally speaking, which might not necessarily be specific to AppSheet.

On data change, in some cases it could be useful to launch different set of actions triggered by a data change, that would depend on the event that induced this change. In a M2M setup for example it is extremely useful to differentiate updates based on the node from which this update has come, some would be more reliable than others and some would have higher precedence over others. In AppSheet, you can for example differentiate between data change induced by user input and another from a webhook, I can imagine.

Therefore, incorporating a wait condition inside the bot, would bound subsequent actions in the bot to all conditions and other actions inside the bot that preceded the wait, while a separate bot listening to data change wouldn't know what triggered that change.

Similarly, one could think of wait for a period.

And as I said, I haven't used it so far, so for me this is rather a mental exercise regarding potential use cases.

Marc_Dillon

Thanks Joseph. I'm afraid I don't particularly understand a large chunk of what you said though. 😞

" In a M2M setup for example it is extremely useful to differentiate updates based on the node from which this update has come, some would be more reliable than others and some would have higher precedence over others."

What is "M2M"? What are the "nodes" in this case? Where/how do reliability and precedence come into play?

"In AppSheet, you can for example differentiate between data change induced by user input and another from a webhook, I can imagine. "

You could with CONTEXT("Host") I believe.

"Therefore, incorporating a wait condition inside the bot, would bound subsequent actions in the bot to all conditions and other actions inside the bot that preceded the wait, while a separate bot listening to data change wouldn't know what triggered that change. "

So I think your main point is that the Wait step is good for cases where certain data change steps must proceed one after another, and no other "order of operations" should trigger the Bot's Steps? I think I can maybe see that being useful.

Sara_Bertomeu

Hello @Marc_Dillon, HERE, there is an example.

Execute when there is some adds or updates, and copy to the table indicates

copy data to another table:

check if the time to date is less than 1 week

if it's true - then send an email to the admin

if not, more than 3 weeks, send an email to another person.

Thanks

Marc_Dillon

Thanks Sara,

If I understood correctly, you're using a 'wait for a period of time' in order to send an email out 3 weeks from the time of the initial Bot trigger?

I suppose that is indeed a case that can't super easily be solved by any other feature in Appsheet.

Well... you could insert a record into an email trigger table of sorts, with an execution date being set 3 weeks from now. Then set up another schedule-Bot that checks that table every day for actions to process.

If I had to guess, I imagine the internal Appsheet system is doing something very similar.

Although setting it up yourself gives much more visibility into it, and you can freely "cancel" the execution, by deleting the record, if necessary, or even changing it.

For a one-off case, I'd probably go with the wait step. But for something that I may be setting up a lot, I'd probably use the home-built setup that I described.

Thanks again for your real life usage!

Joseph_Seddik

>> I'm afraid I don't particularly understand a large chunk of what you said though. 😞

I apologize for this Marc 😔 this is quite embarrassing..

>> What is "M2M"? What are the "nodes" in this case? Where/how do reliability and precedence come into play?

M2M stands for machine-to-machine communications. A node in a network can be an application/network server, a client, a connected device, a router, or any other network element; these are referred to collectively as nodes. In the developing universe, this has been my home planet before my alien-landing on AppSheet's.

In such setup, updates from certain nodes would be of higher priority and could override or reverse other lesser nodes' update, so it is a common, crucial practice to write different routines (bots) based on the trigger's originating nodes.

>> You could with CONTEXT("Host") I believe.

I guess you're right, and that would annul my hypothesis for this case.

>> So I think your main point is that the Wait step is good for cases where certain data change steps mustproceed one after another, and no other "order of operations" should trigger the Bot's Steps? I think I can maybe see that being useful.

Yes, and all other potential cases where we'd have data change happening due to different triggers, and we'd need to launch different set of actions that would depend on the type/origin of the trigger.

______

Italics is way better than this forum's dead quotes. I've borrowed it from you 🙂 thanks much!!

Rifad

I use "Wait for a period of time" in bot to schedule tasks at dynamic times of the day. I used to use schedule bot before, but it triggered only at a certain time that was static.

Let me explain one of the scenarios I use to wait for a period of time and to condition bot. The timesheet table is just a basic clock in/clock out table. Some categories of users should clock out at specific times throughout the day, sometimes at 4:00pm, sometimes at 12:00am, sometimes at 9:00am. Users and administrators can set these times within the app. I use a formula to determine the time between clock in and clock out ex. 4:00pm today. When an employee clocks in at 2:00pm, the duration is 02:00 hours. A column in this row represents this duration. Upon triggering, the bot waits until 02:00 hours is complete and then checks the condition whether the user has already clocked out. The row will automatically clock out if the user does not clock out manually by 4:00pm of the same day.

This has the advantage of eliminating the need to set up individual schedule bots for each time. Additionally, it is more dynamic when it comes to adjusting time and timezone. This bot's execution time won't be precisely 10 minutes; it could be +/- 10 minutes.

Marc_Dillon

Nice setup Rifad, thanks!

SkrOYC

Hi @Marc_Dillon! I had an idea recently and I think that wait may be the solution.

Right now we can't send just one email with a file made via template/bot.

This means that if we want to send multiple files we need multiple emails.

I think that we could have the following scenario:

|-- Bot A fires generation of files, this is a known number

|---- Bot B was fired when the bot A was triggered but is waiting until the three files get made
|---- Bot 1 generates file 1 and creates a path for it (the "access bot file from inside the app" kind of path)
|---- Bot 2 generates file 2
|---- Bot 3 generates file 3
|------ Bot B's Task to send email with attachments gets executed, including the file 1, 2 and 3

I don't know if it would work but makes sense to me.

Anyone has any idea?

Marc_Dillon

That's a good one!

>>"Right now we can't send just one email with a file made via template/bot"

I think you meant to say "right now we can only generate a single dynamic attachment per email/task", which your solution gets around.

EliK

Hi @Marc_Dillon !

I have used the wait condition in two different ways, one a "wait for condition" and one a "wait for a period of time".

1. A process which the final result is an email being sent to a customer, but needs to be approved by a supervisor. The BOT sends a dynamic email to the supervisor, and then sends the customer email as soon as [Approved]=TRUE. This uses the WAI until a condiotion is true, that [Approved]=TRUE.

I suppose I could have had a separate bot be triggered when a record changed to be [Approved]=TRUE, but this seemed simpler at the time.

2. I have a sms sending app, which allows the user to choose what time the SMS should be scheduled to be sent. I need to thank @Rifad for this setup, since I think he responded to my post about it a few months ago. The user inputs the time they want it to be sent, and there is an additional column called [Duration], which is [Timestamp]-NOW(). This produces the amount of time which the bot needs to wait until it arrives at the desired scheduled time. The Bot uses the WAIT a certain amount of time, defined by the [Duration] columm, and then sends the sms at that time. This allows you to "schedule send" sms messages in advance.

Marc_Dillon

Thanks!

Interesting that for #1 you just found it simpler to use the wait for condition instead of building an additional Bot. I'm curious how long you've been using Appsheet? Like was the wait step an available option right when you started, or had you been building automations for a longer amount of time before the wait step was made available?

#2 is pretty brilliant.

---------

In general, I got some pretty good answers on this thread. I'm glad I posted it.

EliK

1. I'm pretty new to Appsheet, the wait feature was already available when I built the bot. It seemed simpler to have one bot that did everything.

2. Thanks! Like I said, it was @Rifad who pointed me to it. It's been tremendously useful. We can broadcast out SMS alerts to our members, and can schedule send it to be sent for the future. Thanks @Rifad!

Joseph_Seddik

@Marc_Dillon wrote:
In general, I got some pretty good answers on this thread. I'm glad I posted it.

I'm also glad you did 😀 Thank you!