I’m hoping to get some insight from those of you who have a deep understanding of AppSheet’s sync architecture.
I’ve always assumed that once a user triggers an action, AppSheet hands it off to the cloud and any background Bots safely take over on the server. However, I’m seeing a major issue when running an action on multiple rows at once.
If a user selects a bunch of records, hits the action button, and immediately closes the browser tab or locks their phone (which is a pretty normal user habit), the entire process cuts off mid-flight. Only the first few records actually update, while the rest of the batch is completely abandoned and their backend bots never run.
My questions are:
Is it normal behavior for a multi-row sync queue to completely terminate if the app or browser is closed before the sync spinner finishes?
Why don’t the backend automations protect the whole batch the moment the button is clicked? How exactly does AppSheet handle this data hand-off under the hood?
If this is standard behavior, what are the available workarounds to force the background process to continue running on the server after the app is closed?
I’d love to understand why this happens and make sure a bulk process runs safely to completion even if a user closes the app right away.
Thanks for the information. You are right, I just tried it by not closing the application during sync(49) but only switching applications for about 5 minutes during sync(49), sync did not continue its activity, it stopped at sync(46). When I tried again. Appsheet canceled continuing the old activity. but instead started with the new sync(6).
I believe row level updates with actions work one row at a time , that is why if 50 rows need to be updated , the user would see a number 50 at the beginning of sync start that gradually reduces with a sync per record at a time. The data change actions work on local copy of the app in user’s device and send the updates for each row in sequence to the backend database server through the AppSheet server in the middle. Please read the section “Improve the speed of sync” in the article referred below to understand AppSheet’s sync cycle.
So any abandonment in the middle, abandons the remaining records to sync.
You could leverage webhooks with AppSheet automation and AppSheet API to invoke updates ( or adds or deletes ) of multiple rows at a time. This would happen on the server side and you need not see multiple syncs.
That makes perfect sense. I didn’t realize it was processing them one by one on the client side before handing them off. Thank you for your inputs, appreciate it!
You can see this happening in the app with your eyes. Please keep your backend data screen of the table on whose summary view you will execute bulk actions open. Execute bulk actions on multiple rows and start looking at the backend table screen. You would see that the rows update one by one as the following GIF shows. The free version of GIF maker I use has a limit of 10 seconds so, it just captures two records updates wherein order status is changed from open to complete for multiple rows through bulk actions. But you can see this happening for yourself for multiple rows - updates happening one at a time.
On the other hand, when you update rows through a webhook, you would see that all the rows update at once as the following GIF shows. All the rows’ statuses change from open to complete at once.
May I know any specific reason for marking @Syamsudin ’ post as a solution?
While @Syamsudin carried out testing to confirm the observation by @Kenriiii , I believe I gave the causal analysis as well as solution to @Kenriiii 's question which @Kenriiii has also clearly agreed as a solution which the below screenshot from this post thread shows
I have always encouraged fellow community members and @Syamsudin is also a budding, enthusiastic community contributor. So I am always happy for him.
However I believe I spent a substantial effort in understanding and explaining the issue and providing a solution in detail. My solution post has also been liked by 6 community members , indicating an acceptance.
Hi Suvrutt. Seeing the two processes side-by-side makes it so much easier to understand what’s actually happening. This is exactly the kind of deep dive I was looking for to figure out how it works under the hood. I’m definitely going to explore using webhooks for this now. I really appreciate you taking the extra time and effort to share these. Thank you!
