Not sure if there is an easy solution for this. We have multiple users that will edit rows to add or change information. If user1 makes a change on a record, but then user2 makes another change on the same record before syncing, then user1’s changes will not stay.
Thanks
Kyle
This is an excellent point. If these permissions are granted to these people then yes, it cannot be stopped. There are however ways to get around this, ways to make things different.
First you can restrict some users privileges or change you table permissions if you do not want edits to be allowed and instead you can only add and delete entries.
You could also give certain users more permissions than others, this can be done by adding a role in the users table then adjusting the same edit, add, and delete permissions at the table level by using the following expression.
ANY(SELECT(User[Role],USEREMAIL()=[email]))
With that expressions you can do several checks to see if the user is an admin or worker or whatever else. Additionally multiple people should not be making a change to the same information, that sounds like a company job description and responsibility needs to be clarified. Also, you could set rows so they are only editable by the people who created the row and admins. That could be another way to solve your problem.
Hopefully that makes sense, if you need more help let me know and I can assist further.
Craig
QREW Technologies
Generally speaking, not limited to AppSheet, this is a problem of bad design.
Your design should NOT allow more than one user or event to have direct write access to the same row in the same table.
Here’s an advice that can be as specific only as your original post.
What you need to do instead, is to log change requests as rows in another table, then the app’s logic will make appropriate corresponding decisions to update the rows in your original table based on these change requests.
@Craig_QREW I have to make a small comment please:
Good business tools are organizational enablers, not organizational constraints.
Right we do want these apps to be user friendly and encourage collaboration among each others. However I was just recommending to look into practicing the principal of least privilege. Generally it is regarded as a best practice. This just makes things so that you don’t run into these kinds of problems. But yes something to think about.
Craig
QREW Technologies
I agree. And I actually like the idea of least privilege. Sorry, I was referring rather to the second part about roles and responsibilities. Although this is better more often, some organizations just cannot afford certain levels of role specialization. Hence, their business tools should adapt to and emulate the organization as is and evolve with them. I mean organizational change should be business- rather than tool-driven.
That makes sense. Thanks for your input.