LinkedIn
Twitter
Thanks @praveen for the explanation of conflict resolution in AppSheet, here and the documentation describing of the “last writer wins” approach by Santiago Uribe Montoya.
This request includes rather a lengthy justification, so I’ve emboldened the key points for clarity, not for shouting. 
An update conflict can occur where two or more users independently update the same row at approximately the same time such that they do not see the other’s update before their own is applied. They both look at the state of a row and decide to make an update (like booking an airline seat). Only one of them will get the seat but in a conflict it looks for a while like they both got it. One of them is later to be disappointed and is left scratching their head.
I understand that AppSheet does not attempt to resolve or prevent update conflicts and agree (as @praveen points out) there is no reliable and performant, general solution to resolving update conflicts.
I note that AppSheet takes the “last writer wins” approach and AppSheet does not detect the conflict condition and so cannot inform one of the users that their update failed.
If the default view navigation immediately takes a user to a Detail View to see their update they might be aware that something didn’t “stick”. However, I note that the client cache means that this view frequently suggests that the update did stick, so this is not much help.
I can see the AppSheet audit log contains sufficient detail to explain ‘lost’ updates, given sufficient time and experience with the log analyser. So a user raising a ticket can get a rational explanation as to what happened. Nevertheless, the user may not be very happy about it and, if it happens often enough, is a source of frustration and rumours of unreliability (unfounded or not).
Broadly speaking, this is an entirely reasonable approach, although, I suspect it may come as a bit of a shock to some developers.
However, because the “apparent” loss of an update is opaque to the user, the user may raise a support ticket complaining they ‘lost’ data or the system ‘forgot’ an update or ‘reverted’ to an old version.
Also, it is application dependent as to whether or not lost updates are benign. “Last writer wins” provides no guarantee that the resultant state is correct. In fact, it deliberately dodges the issue, leaving it up to the application developer. In this sense, “last writer wins” is not as such “a conflict resolution strategy”. While this is completely understandable, we must accept that AppSheet cannot guarantee ACID properties.
I also note that AppSheet is a no-code platform and while I do appreciate that app developers have an obligation to work diligently to prevent or reduce conflicts, this is an acquired skill and perhaps not entirely compatible with a no-code platform.
While accepting that resolving update conflicts is not feasible, detecting them is. For example, update conflicts can be detected without unduly impacting performance using something like versioning or optimistic concurrency control.
For example, by comparing a manifest (checksum) of a pre-update copy of a row for consistency with the pre-update image when updating the ‘real’ record at the back end AppSheet could detect update conflicts and let the user whose update ‘failed’ know that they need to retry. This would mean abandoning “last writer wins” in favour of “inconsistent update fails with an error”. In this example, error processing need not be synchronised with the updater as long as there is a way to let the user know with the next sync, which simplifies client behaviour changes.
A plausible business case for this feature request might include:
- reduction in user reports of ‘lost’ updates
- reduction in consequent user frustration
- savings in support effort
- protection of platform reputation