I use an Integromat Webhook to send data to 3 columns. Working fine.
In the AppSheet App I have an Action that sets 2 other columns: A Yes/No column and a DateTime column. Also working fine.
Now when the Webhook sends data to the 3 columns and the user hits the Action to fill the other 2 columns, AppSheet will override the 3 columns.
Why: The App has not yet fetched the 3 columns that Integromat sent to AppSheet via Webhook. So for the App these 3 columns are still blank. That why it clears them out.
How can I tell the Action: Donโt touch these 3 columns?
I tried Editable? CONTEXT("Host")="Server"
but this does not help.
I found that I could solve it via a Form based on a slice. This slice does not include those 3 columns. By saving the form, the 3 columns will not be touched.
But I donโt want to use a Form. I want to use an Action.
Whatโs the action btw?
Are you certain that when you used the Form approach, that the row hadnโt been updated by a background Sync?
Also, is your action running on the server or on the device - i.e. is it part of automation or is it an action executed by the UI such as on Form Saved or Row Selected.
If it is an action run on the server, then I would simply add the 3 columns to your update action and RE-ASSIGN them the same values. That way if they were updated, you would get the updated values, at least I believe you would, because any update expression would run against the server datasource.
Yes Iโm certain. Itโs working. Maybe itโs not supported by AppSheet but itโs working.
You can try it out:
You will see that the column you changed in the Spreadsheet will not be changed by the AppSheet Edit.
The Action is executed by the device. The user hits the Action button. It cannot be done by automation, because I immediately need the result for further UX.
I donโt see a way, presently, to prevent the issue you are experiencing. The ideal thing would be to force a Sync After the user taps the button but before the Action makes its update. We, unfortunately, donโt have a mechanism to be able to force a Sync in that way.
As for the Form NOT overwriting columns while the action edit does. This seems like a consistency bug. Why these two ways to update a row are behaving differently isnโt apparent to me. It would be nice if actions would only update the columns that have changed. It would eliminate issues others are experiencing.
Doesnโt we?
@Fabian
Create a new action.
Assign the expression from the post with a โgo to another view withinโ kind of action.
Then, replace the current action button with a grouped action that has the force update action first and then the one that you are using today.
It should work
This wonโt work in @Fabian 's use case.
@Fabian already has an option to use a Form to make the row edit which would resolve his issue but he didnโt want to do that. He wants the user to tap a button and the action makes the data change but the action is overwriting columns just set by a webhook. A Sync needs performed BEFORE this Data Change action so the row edit has the most recent values.
The only way we have, that I am aware of, to perform a force sync is using Deep Links to go to a view and tack on a URL property. Since any navigation to a view halts action processing, the data change would not be peformed.
He wants the user to tap a button and the action makes the data change but the action is overwriting columns just set by a webhook. A Sync needs performed BEFORE this Data Change action so the row edit has the most recent values.
The only way we have, that I am aware of, to perform a force sync is using Deep Links to go to a view and tack on a URL property. Since any navigation to a view halts action processing, the data change would not be peformed.
I think you didnโt see the post I linked to because thatโs what it does
Regarding the second part, I donโt know if after the sync the app will remember the next part of the grouped action, I always use it as the last action to be performed. Worth a try
I think you didnโt see the post I linked to because thatโs what it does
I read it. Maybe I donโt understand it. The behavior is not explicitly explained. It looks to me that a Deep Link is constructed and uses the current view.
Is your assertion that the app will force a sync without physically changing views?
More importantly, if I place this in a Group action with a Data Change after it, the Data Change action will still execute?
I tested this out and it doesnโt seem to help.
Below is a Grouped action. The โForce Syncโ is the suggested CONTEXT(VIEW)
expression. The โChange Quantityโ will attempt to set the Quantity field to 998.
After running the action, a Sync DID occur and the Number column was updated by the Sync But, unfortunately, the Data Change action was NOT executed.
Result after running action - no changes to Quantity data
Thanks!
So, after the testing, we can assume that the force sync action stops any other action and should be used as the last one on a grouped action. (Iโm gonna add that as an update to the OP about force sync)
Worth a try as I said, itโs sad that it didnโt helped.
So we are in front of a wall that may be fixed with the future with some kind of real time database support from my pov
Now when the Webhook sends data to the 3 columns and the user hits the Action to fill the other 2 columns, AppSheet will override the 3 columns.
This two interactions are made by the same user, one via integromat and other via the app?.
How is the integromat webhook configured?
Why: The App has not yet fetched the 3 columns that Integromat sent to AppSheet via Webhook.
Bcz there is no real time support so if there is data made via api the app wonโt tell after the sync, similar to two users using the same app and changing column values.
What you refer to โoverride the 3 columnsโ means that you expect data on those 3 but then one is blank and the other two have the values from the action? Thatโs where Iโm lost.
How can I tell the Action: Donโt touch these 3 columns?
Actions = The button from the app? Those are configured on a column-basis so if you need to leave 3 of them out, you just do exactly that.
I may sound rude, sorry, chatting isnโt easy but I want to help.
Could you explain a little bit better the integromat part? Itโs another action thatโs called via api?
Thank you @SkrOYC and @WillowMobileSystems.
Yes, a forced sync is a navigation action. And navigation actions are always the last action in a grouped action. Any other Action after a navigation action will not fire.
It would be nice if actions would only update the columns that have changed. It would eliminate issues others are experiencing.
Thatโs also my opinion. Maybe I will ask AppSheet support.
How can I tell the Action: Donโt touch these 3 columns?
You canโt. All updates are row-based: the entire row is updated at once. When the user clicks the button, the two columns of the row are updated. The entire rowโincluding the two updated columnsโis sent as the update during a sync. That entire updated row then overwrites whatever row is in the data source.
Yeah thatโs what I saw. Itโs like 2 users working on the same row: The last sync will win.
But this is not the case when you use a form based on a slice. With that you can exclude columns.
You can try it out:
- Edit a row via a Form based on a slice
- In the Spreadsheet enter a value in the column thatโs not included in the slice
- Change something in the Form
- Save the Form
You will see that the column you changed in the Spreadsheet will not be changed by the AppSheet Edit.
So it should be possible to exclude columns also in data change actions.
Right now we can base a form on a slice. But we cannot base an action on a slice.
Hello Fabian,
Generally speaking, regardless of the platform/environment, when I have data fields that would be updated by some remote events, and I know that one event has precedence or higher priority over the others, but I cannot be sure of the order in which these events would arrive, as a rule of thumb, I always use a separate buffer to register the input of the high precedence events, then launch actions based on their arrival.
So in your situation, I hope I understood correctly, we have the 3 columns that gets updated as a result of two separate remote events: either by user clicking an action button, or by the Webhook.
Since I want the Webhook to have precedence and to protect itโs input, I would do the following:
Restrict the lower precedence button action so that it only updates the fields when they are blank, which I understood you are already doing.
Make the Webhook update other fields away from the three columns in question; for example: other buffer columns in the same row or even another buffer table. I would personally go for adding a new row to another table.
Using automation, I would monitor the buffer table and trigger an action upon new row addition. This action will fill in the values of the desired 3 columns, and it will be triggered only when the Webhook input has been duly received and recorded in AppSheet, regardless and with complete independence of the low precedence event (user clicking a button). Thus, I can now be sure that my Webhook data will not be overwritten.
I would then delete the new row from the buffer table; which is of course optional.
I hope it helps.
Hi @KJS thank you very much for taking time for this response.
My usecase is a bit different: The Webhook fills 3 columns and the Action fills 2 other columns of the same row. If the Webhook fills the 3 columns and a bit later the user hits the Action, his device does not have yet received the Webhookโs data entries. As we know, the action data change will send all columns to the sheet. Also the 3 columns that are empty in device perspective. Thatโs why they get cleared out in the sheet.
But anyway you gave me a hint: Maybe I will use an extra table for these 3 columns. With that my problem would be solved.
So I donโt need anymore the SelfRef to build an inline deck view, but can use the system generated ref view.
Thanks @GreenFlux this is cool. We are using Integromat to get the actual weather, based on the GPS position. [image] After adding a row in AppSheet it sends a webhook to Integromat. Integromat sends a HTTP back to AppSheet. I then made a SelfRef and built an inline deck view. [image]
But anyway you gave me a hint: Maybe I will use an extra table for these 3 columns. With that my problem would be solved.
This is fine for maybe one or two cases but imagine if an app needed many?? Ouch!
As we know, the action data change will send all columns to the sheet. Also the 3 columns that are empty in device perspective. Thatโs why they get cleared out in the sheet.
I understand well. I think keeping the three columns in a separate table is a perfect solution and an easier one.
But if for some reason you need to have them in the same table, you can still use the same solution; it is especially made for this case.
You just monitor the row and launch an action upon data change. This action will check whether the buffer fields are not empty and, since they have precedence, will just copy their values to the table regardless of the existing values.
So here it goes:
What if the action you are using is changed by an action that triggers a bot that makes a call to the AppSheet API?
This way both changes are made through server and should be made in order.
Am I wrong? @Fabian @WillowMobileSystems
The user has to see the data change immediately in the device. Because based on the data change, other actions appear in the UI. Thatโs why I cannot use a Bot for that.
You could use a bot + the forced update
You could use a bot + the forced update
Can you confirm that this works? I thought you would need 2 syncs: One to fire the bot and second to receive the data.
But anyway: Users donโt have time to wait for a sync during their work. I would use the forced sync very rarely. Like the last option if there is no other way.
Another strange observation:
If I disable the โEditable?โ in the 3 columns, the data change action will not touch them. It wonโt clear the values.
But in the following cases, the data change action will clear the values:
Editable?
FALSE
CONTEXT("Host")="Server"
CONTEXT("View")="A_View_That_Does_Not_Exist"
TODAY()="04/22/1970"
Disabling Editable? is NOT the same as setting the Editable? expression to something that evaluates to FALSE
.
Disabling Editable? makes the column entirely read-only. Under no circumstances will AppSheet modify the contents of the column.
If Editable? has an expression that evaluates to FALSE
, the app user will not be able to edit the column value (e.g., within a form or Quick Edit field), but the app itself may (such as with App formula, Initial value, and actions).
Thank you @Steve for this nice explanation.
So I think I can go also this way:
I disable the Editable? in the 3 columns.
I will not use a webhook to send the data to appsheet, but I will use Integromat to send the data directly to the Google Sheet.
Yep. If a column will be routinely updated outside of AppSheet, the column is a good candidate for Editable? disabled.
If I disable the โEditable?โ in the 3 columns, the data change action will not touch them. It wonโt clear the values.
This is Tips and Tricks worthy!
User | Count |
---|---|
19 | |
9 | |
8 | |
6 | |
5 |