In a web application, the team is interested in providing the following functionality:

  • User A select an object from a list
  • User A edit that object in a separate window
  • User B select the same object from the same list (at the same time User A edit it)
  • User B edit that object
  • User A save or delete that object
  • User B gets a notification on the object edit window with an option to undo the changes User A made.

My perspective is that we are complicating something unnecessarily. The above scenario can get confusing. For example, User A after saving changes, will open that object and will not see the changes. Or if deleting an object, the user will still see that object.

I know Google does it in documents, but the application I am working on is not for editing documents but maintaining a large network system, which is a different use case and workflow.

When I asked the developer why not just disabled the object while in edit mode to other users, the reply was that the object list should be actionable and never just a simple object list. It was also mentioned that locking an object is "unfriendly." I find it more confusing and over complicating having the notifications with the additional actions.

What would be the best approach in that case? Locking an object while in edit mode, or object can be edited at the same time by two or more users, and provide notifications and actions to revert any changes?

  • How big is this 'multiple users editing same stuff' use case in your system? It slightly sounds like the solution could be over-engineered. Commented Nov 14, 2018 at 8:43

3 Answers 3


Locking an object is unfriendly because humans have a horrible habit of putting something in edit mode and then going away to do something else. Worst case scenario you can have someone edit it and then go on holidays for 3 weeks.

Usually it is better to let multiple people into the edit mode, and then notify of other changes. To avoid race conditions, you can make sure that your API sends the information about the "original state" that the edit mode saw, and rejects any edits that have been sent where the "original state" is not the current state of the object being edited.

  • The system could save their changes as a draft. And release an item when it's been locked for more than 1 week. Commented Nov 14, 2018 at 8:45

You can display the information "User A edits this object" on front in the list. If User B decides to edit the object anyway, he gets a dialog box similar to WordPress. "User A is currently editing this object, would you like to take over? - NO - YES"

With the confirmation user A is kicked out with a hint about this action and his changes are lost.


This situation also occurs in GIT - when there is a file conflict (when A and B are editing one thing at the same time)

enter image description here

A lot depends on the data that is being edited at a given moment and from what level (interface, code, console, program)

The possibilities:

  • Blocking element, when one user editing item.
  • Provide a conflict resolution system.
  • A good idea is the chrisbergr idea (informing that a person is working on a document) - a competent person will then take on another task or suspend with the action - the problem arises when someone is in the document - but does nothing.
  • Introduction of the Supervisor role - which approves changes at the end of the day, having all editing options.
  • When closing the document by B - display the conflict in the data to be resolved before closing by B.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.