As we all know, we still often have to rely o...

[Christian_Farle]

As we all know, we still often have to rely on backend google scripts to do more complex operations like multi-row aggregations and such. This forces us to prompt our users for multiple refresh after a single entry. This is a pretty significant user experience killer, not to mention the high risk to data consistency. Are there any progresses made towards resolving this weakness?

I may be oversimplifying, but what is needed is a mechanism, or a column type, that says to appsheet that this row must complete a backend script operation, and that it needs to be refreshed once more transparently to the user (from the user perspective it is a single save operation). Obviously this would be super time costly, but never as costly as having to do multiple refreshes. And a much better workflow.

For example: Let’s say we have a new column type called “Callback”. This tells appsheet that it must cache the row data from a form save operation, and that it needs to re-read the row in n miliseconds, and if “Callback” value = “Done” (which would have been set by the backend script), it re-saves the whole row. There could also be a “number of retries” parameter on the Callback column, so if the Callback value is never set to “Done” (because the backend script is failing) the complete row update is canceled with an appropriate error message.

[Christian_Farle]

@praveenHi Praveen. The scripts are synchronous. They are executed after a row update, scheduled as an OnChange event. Also note that one of the function creates new rows following the changed row.

[Aleksi_Alkio]

There is an idea behind of this post, no doubt. On the other hand… if we could reduce the background syncing cycle a lot, which is now 30 minute, it could do the same behavior. Adding @praveen

[pravse]

@Christian_Farley2, I assume the backend script you are running is asynchronous? Solutions based on timing are brittle.

However, @Philip_Garrett_Appsh is currently exploring using a mechanism that will notify our system when changes occur to the sheet, and then use that to notify the apps as well. This is a multi-month engineering investment but its goal is to solve for all these cases where the data in the app is stale or needs manual refresh.