search string side menu

System architecture and requirements / Prevent data save conflicts

Prevent data save conflicts

When multiple users edit the same app item simultaneously, a conflict may occur during saving. This will result in changes not being saved, data loss, and the system displaying outdated information.

To solve this problem, the following has been implemented:

  1. Atomic attribute changes. Only the edited fields are saved, not the entire item.
  2. Conflict control and locking record of changes. If a conflict exists, the user receives a notification to refresh the page before saving again. The save button is temporarily disabled.
  3. Server-side item version checking. The item contains a unique version identifier __version, which is updated on every save.

When a user opens an item page, the current attribute value is loaded from the server. After the user finishes editing and saves the item, a version check is performed on the server:

  • If the versions match in everything except the user's changes, the server version is updated.
  • If the versions do not match, it means the item was modified in parallel. The user's changes are rejected with a "version inconsistency: collision" error. The user will see a conflict notification asking them to refresh the page. The save button is locked.
  • If the user changed field values but then reverted to the original data and saved the item, a version with no actual changes is returned to the server. The attribute value remains current.

The save conflict handling mechanism is applied:

  • When users manually open an item for editing.
  • When modifying an item as part of a business process, script execution, or Web API methods.

To activate conflict protection, enable the Prevent save conflicts option in the app settings.

Please note the following limitations:

  • Conflict prevention is only available for custom app properties. Notification is not sent when system fields (e.g., status) are modified.
  • Change tracking is not supported in the access permissions or when deleting an item.
  • Simultaneous data editing within bulk actions is not processed.

Use cases of preventing item save conflicts

Case 1. Users editing an item simultaneously

    1. User A opens a client page and edits the Phone number field.
    2. At the same time, User B opens the same page and edits the Email field.
    3. User A saves their changes.
    4. As a result, User B receives a notification: "Item has been changed! To avoid data loss, refresh the page before proceeding". The Save button is temporarily disabled.
       
      User B refreshes the page and sees the current phone number entered by User A. They can re-enter and save the new email.

Case 2. Item edited simultaneously manually and within a business process task

    1. A business process is configured in the system where User A receives a task to modify the item's data. They edit the Email field.
    2. Simultaneously, User B opens the same item's page, edits the Phone field, and saves the changes.
    3. User A receives a notification: "Item has been changed! To avoid data loss, refresh the page before proceeding". The Save button is temporarily disabled.
       
      User A refreshes the task page, sees the current number entered by User B, and can re-enter and save the new email.

Case 3. Item edited simultaneously manually and within a script execution in a business process

    1. User A opens a client page and edits the Email field.
    2. Simultaneously, User B starts a business process where a script automatically changes the same client's email.
    3. User A saves their changes.
    4. If the process instance has not finished executing yet, it will fail with a "version inconsistency: collision" error. The data entered by User A will be saved on the server.
       
      If User A saved their changes after the script executed, they will receive a notification: "Item has been changed! To avoid data loss, refresh the page before proceeding". The Save button will be temporarily locked.
       
      User A refreshes the page, sees the current data, and can re-enter and save the email.

Important: For this case to work correctly, in the Script activity settings on the Error Handling tab:

  • Disable the Retry option to avoid infinite retry attempts.
  • Enable the Notification option and select a recipient for the error alert. The administrator can resolve it in the error monitor and, for example, restart the process.

Case 4. Item modified simultaneously manually and via Web API methods

  1. User A opens a client page and edits the Phone number field.
  2. At the same time, a request to update the same field on the same page is sent via Web API from an external system or another user.
  3. User A saves their changes.
  4. If the Web API request has not yet completed, it will return a "version inconsistency: collision" error. The data entered by User A will be saved on the server.
     
    If User A saved their changes after the request was executed, they will receive a notification: "Item has been changed! To avoid data loss, refresh the page before proceeding". The Save button will be temporarily locked.
     
    User A will refresh the page, see the current data, and can re-enter and save the number.

Case 5. Item edited simultaneously manually and within a script execution in a widget

  1. User A opens a client page and edits the Phone number field.
  2. Simultaneously, User B clicks a button on the same page that triggers a script to automatically change the client's number.
  3. User A saves their changes.
  4. If the script has not finished executing yet, a "version inconsistency: collision" error will be returned. The data entered by User A will be saved on the server.
     
    If User A saved their changes after the script executed, they will receive a notification: "Item has been changed! To avoid data loss, refresh the page before proceeding". The Save button will be temporarily locked.
     
    User A will refresh the page, see the current data, and can re-enter and save the number.

Error handling in scripts using try–catch

To prevent scripts from failing due to save conflicts, you can use a try–catch construct for error handling.

Let’s see the case:

  1. User A opens a client page and edits the Phone number field.
  2. Simultaneously, User B starts a business process with a script that receives a task to modify the same item and enters a new number.
  3. User A saves their changes.

If the script has not yet completed, a "version inconsistency: collision" error will be returned. The try–catch will trigger, the error will be handled automatically, and the script will continue executing. The data entered by User B will be saved on the server, and User A will receive a conflict notification.

version-support-elma365-on-premises.html external-extensions-elma365.html