Check backend before update to prenvent duplicate ID or information in the same row

[hien_nguyen]

I have a big problem after few months deploy Appsheet for my team.
I think with curent solution In order prenvent duplicate ID when adding a new row by using uniqueid() is ok. But if I arrange multiple users can assess for updating information in 1 rows, it be often overwrited in formation because user user update later didn’t syncing app before update. So the last infromation from last users be overwrite. I have many complaint every day for this issue.
I hope appsheet will update new feature that user can check backend before update. I system change content in database different with value in current app, it will show a alert to prenvent user overwite or notification before saving?
Thanks,

Hien Nguyen

[MultiTech]

This is why you don’t build a system where users can overwrite each other

• Instead, users should create individual records, and those records then affect the “actual” record

---

Yes it’s easy to build a simple app; where I have the ability to press buttons on records to modify them, where I can use quick edit fields to make filling in things faster/easier/simpler for people.

But the cost is that multiple people can’t use the system simultaneously - at least to modify the same records.

---

---

An Example

I had a client years ago that operated a dorm room furniture rental service. Part of that service was installation of the beds, desks, couches, dressers, etc., and the way they handled this was pretty innovative.

So each order had various line items (each line item being a single piece of furniture that needed to be moved somewhere), so at the beginning of moving day there was a giant list of records that contained all the information about what to move & where.

In order to move everything, the solution was to “freelance” it out to the college kids.

• We created an app where people can log in, create an account, and “claim” items to move.
• This gave people that had certain things down, like assembling and moving bunk-beds, the ability to claim a bunch of these and do them all in one shot.
• Each item had an associated [Pay_Rate] (moving a microwave paid less than installing bunk-beds)
• People could claim as much or as little as they wanted

But obviously we couldn’t have 60+ people logged into the same app, each trying to modify the same records - you’ve found out how well that works.

• You’d end up with one person claiming a record, and another claiming the same thing because the app of the second person didn’t have the edits of the first.

Solution: We created a “Item_Claims” table

• This was a child to the “Order_Items” table
• It gave us a way to record: this item + this person
• Since the user is submitting a record, and not modifying something already there, the edits made by the user are unique - and therefore won’t interfere with others.

To handle the possibility of duplicate claims we created an automation (workflows back then) that fired off when a new “Item_Claims” record was made.

• This checked to see if there was already a claim for that Order_Item
  • If there was, the submitted “Item_Claims” record had it’s [Claim_Status] marked as a “duplicate” and the user was sent a notification notifying them that item had already been claimed.

It was only by creating a way for each user to submit unique data, then implementing a system to check for duplicates and handle them, that I was able to smooth out the flow of this sort of app interaction.

---

---

Think about the following scenario:

I have a record that holds "how many hours were spent working on a particular project"

• I wouldn’t create a system when each user would simply “modify” the total of the project record
  • Sure… I COULD create an action that simply added 1 to the total, and users could simply hit that button X times to add their time…
  • Or I could make the [Project_Total_Time] field a quick edit, on the detail view, so people can easy change the value…
    • But each user would be overwriting the other

Instead I would create a system where users could submit timelogs, ref-connected to the project

• I would then use List-Dereferences to efficiently get derivative data from the child records, and calculate the [Project_Total_Time] that way:

SUM([Related TimeLogs][Total_Time])

By having each user submit an individual record, and then correlating that data afterwards on the parent level, this is how you can create a multi-user system that won’t have users overwriting each other.