Conflict Detection

A request holds the values as they were at submission time. The master data can move on while the request waits. This page describes what Primentra does when the two no longer agree.

How a stale record is detected

Every changed record in a request stores the moment its live row was last modified. When the request is opened, Primentra compares that moment with the current one on the live row. A newer live row marks the change as a conflict, and the API returns the flag with the request detail.

Locking keeps most conflicts from ever happening: a record with a pending change cannot be edited in the grid. A conflict therefore points at a change from another path — an import, a staging batch, the REST API, or an administrator.

Concurrent edits

Approval applies the submitted values. It does not merge them with what changed in between. The submitted value wins and overwrites the current one.

Only the attributes present in the submission are written. An attribute that was not part of the change keeps its current value, even if someone else changed it in the meantime.

Duplicate codes on a new record

A new record whose code already exists in the entity cannot be inserted. Primentra marks that single record as rejected and continues with the rest of the request. Nothing is overwritten and no duplicate is created.

Check the record status in the request afterward. A request can close with some records applied and one refused.

Deletions

A deletion is applied as submitted. There is no check on whether the record changed after the submission. The record and its values are removed.

If another open request also referred to that record, its link to the record is cleared. That request no longer targets live data.

Business rule failures

Business rules run after the values are written, inside the same transaction:

• A warning is recorded and the approval continues.
• An error rolls the whole approval back. Nothing is applied, and the panel reports which rule failed on which attribute.

Fix the data or the rule, then approve again. See Rules in Approval Workflows.

Reducing conflicts

• Keep approval queues short. The longer a request waits, the more the data can drift.
• Route bulk loads through the same entities with care. Staging and imports do not respect an approval lock.
• Use Send back rather than Approve when the diff no longer matches what you expect.

Related

• Role: Approver — where the diff and the decision buttons live
• Approval Workflows — record locking
• Rules in Approval Workflows — how a rule refuses an approval
• Audit Panel & Read-Only Fields — who last changed a record