# Prevent data save conflicts
> [HTML Version](preventing-data-save-conflict.html)
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 \[OBJECT\], 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](360007708691.md).
````
Начало примера
````
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 the following 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](360027203731.md#error-handling-tab) 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](error_monitor.md) 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 \[OBJECT\] 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 changes the phone number of the same client.
3. User A saves their changes.
4. If the script has not yet completed, the data entered by user A will be saved on the server. The script will continue to run, and the returned error “version inconsistency: collision” will be automatically handled using \[OBJECT\].