Order of Operations Issue? - Incorrect Column Data Sent to Chat via Webhook

[mykrobinson]

I created an automation today to send information to an internal chat via webhook based on a record update. The idea is that if a patient record is flagged In Hospital, a chat message is sent to the Registration team so they can confirm some information is up to date in another program.

The first step is checking the record in the Patients table upon update and firing off the automation if this condition is true:

AND(
[_THISROW_BEFORE].[In Hospital]="FALSE",
[_THISROW_AFTER].[In Hospital]="TRUE"
)

then a message is sent to chat via webhook like so:

{
    "text": "*<<[Full Name]>>* , 
 *<<[DOB]>>*, was marked *In Hospital* at *<<[Hospital].[Hospital Name]>>* on *<<Today()>>* \nPlease verify that Epic information is accurate."
}

 The problem I am seeing is, in my tests, the message is being sent but not necessarily the correct hospital name. I changed hospitals on our test patient Demi Lovato from WTH-D to BMS-UC, but the previous value was sent instead:

My theory is that this has to do with order of operations, and the message is being sent as the change processes when the record is saved, but BEFORE the location change is saved.

How can i unsure that accurate information is being sent in the chat message? can I delay the message until the entire record is updated?

[Marc_Dillon · Accepted solution]

>>"For example, if I mark a patient "in hospital," change the hospital, and change the room number, 3 record changes are queued for that patient, as indicated by the notification at the top right of the app."

That's not a single data change event, that's 3, and that perfectly explains why your webhook does not have access to the new [room] value. Every data change, there is a "snapshot" of the current full set of data. When a Bot runs, it only runs on the current snapshot. Your Bot is running when the [status] value changes, so that snapshot holds the old [room] value (because it hasn't changed yet).

I assume the app-user is making these changes with quick-edit fields on a Detail view? The easy solution is to just change that to send the user to a Form view to edit those 3 specific values. That Form view could also be an INPUT() dialogue instead of a standard Form view.

The other option would be for your Bot to trigger on the change of the [room], instead of the change of the [status].

[Marc_Dillon]

Is the [Hospital] value being changed within the same data-change event as the [In Hospital] value?

[mykrobinson]

Yes. Granted, typically, a patient who is readmitted will return to the same hospital, but i am a firm believer in thorough testing and planning for possibilities 🙂

So as a registration person (not sure what the right word is here) is flagging a patient as "In Hospital" in the app, it reveals a few more columns that allow them to select the current hospital and input the room number, all done in the same event.

[Marc_Dillon]

It should be sending the new value in the webhook then. Do some more thorough testing with it. Or perhaps there's some detail that you're leaving out?

[mykrobinson]

Still having trouble with this. I watch the automation fire off as the record is saved. The record shows to have multiple changes, and it looks like the automation is happening as soon as it realizes the In Hospital state has been changed.

For example, if I mark a patient "in hospital," change the hospital, and change the room number, 3 record changes are queued for that patient, as indicated by the notification at the top right of the app.

As that number decreases to 2, the automation fires, since it satisfies the check for "the column was false before, and it's now been changed to true."

I somehow need to add a delay so the automation doesn't fire until all changes queued for that row are completed.

[Marc_Dillon · Accepted solution]

>>"For example, if I mark a patient "in hospital," change the hospital, and change the room number, 3 record changes are queued for that patient, as indicated by the notification at the top right of the app."

That's not a single data change event, that's 3, and that perfectly explains why your webhook does not have access to the new [room] value. Every data change, there is a "snapshot" of the current full set of data. When a Bot runs, it only runs on the current snapshot. Your Bot is running when the [status] value changes, so that snapshot holds the old [room] value (because it hasn't changed yet).

I assume the app-user is making these changes with quick-edit fields on a Detail view? The easy solution is to just change that to send the user to a Form view to edit those 3 specific values. That Form view could also be an INPUT() dialogue instead of a standard Form view.

The other option would be for your Bot to trigger on the change of the [room], instead of the change of the [status].

[mykrobinson]

thanks for that. while i don't like it, at least i understand it :joy: I suppose i was under the assumption that the bot would fire after all changes to the record were completed, but it is quite literally happening the moment the one column i am watching in the record changes.

and you are correct, the values are being changed via quick edit.

I do see that AppSheet has an option to add a delay, with a minimum of five minutes. I may test that option, because this particular feature doesn't necessarily need to be in real time. What i think will end up happening if I add the five minute delay, the people that need these messages will still be receiving all of them around the same time, since the "in hospital" list is currently updated twice daily.

[Steve · Accepted solution]

With Quick Edit in a detail view, each column change is sent as a separate edit.

Quick Edit - AppSheet Help

[mykrobinson]

ahhh.. this makes sense and explains it. So, theoretically, if I implement the five minute wait for the automation to trigger, it would then reflect the current state of the row in question? Probably a better way out of this pickle, but i may as well play "what if" with one possible option

[Steve]

Each individual Quick Edit would trigger another waiting bot, so you'd end up with some redundancy. Not how I would do it.

[mykrobinson]

I'm going to abort my usual "subtle hints only" approach and ask, how would you do this if the end user(s) prefer the quick edit option for the columns in question?

[Steve]

I was afraid you'd ask this. I really haven't considered other options. Just on the surface, redundancy rubs me wrong and has a tendency to cause problems, so I try to avoid it.