This is a pretty common problem, and one of the reasons that web applications tend to commit right away after any change. Sometimes the right answer is do nothing. You have to decide up front how you intend to do this in order of complexity:
- Last commit wins (default behavior)
- Actively lock the record to prevent edits
- Update screen if changes detected
- Resolve conflicts after attempted commit (last because it's least favorable)
The behavior you are experiencing now is that the last person to save changes wins. It's not always a wrong answer, particularly if the amount of data is pretty small.
Active locking can be a necessary pain if you are committing a lot of changes all at once. The overhead to be able to support proper record merging is pretty high, so it's easier to prevent other people from being able to edit the record. You'll need to naturally expire the locks if the user neglects to unlock the record.
Single Page Apps (or desktop apps) have the luxury of being able to provide a much more granular level of integration. It helps if you allow server push to anyone with that record open. When you have the ability to push change notifications, the UI can update the UI to reflect what is currently on the server. In the case where someone else is editing the code, you can at least see what is on the server next to what you typed. This is pretty complicated, but if you can send patches from the SPA to the back end and vice-versa, it's possible. Even better, if the UI only has one control in edit mode at a time, the changes are much more fine grained.
The last option is to use versioning on your data, and detect the version of the data that you are changing is old on the server. In that case, you can send back a response for the user to manually edit the conflicts. This is a pretty crappy user experience since it's on the user to hunt and find where things have changed.
You have to choose which of the many ways to handle this problem fits your application best. Sometimes the user will request active record locks. Sometimes they will demand the highly interactive version. There's tradeoffs, so you'll have to work with your user community to really select what's going to work best from an effort/time perspective.