Troubleshoot update conflicts
A conflict means the requested change could not be applied safely. It can indicate an outdated record version or a valid domain rule that blocks the action in the record's current state.
The application commonly displays messages such as Conflict: [reason] Refresh the equipment record and try again; your changes were not applied.
“The record changed elsewhere” or a stale-version conflict
Likely causes, in safe-check order
- Another user saved the record after you opened it.
- The same record was changed in another tab or browser session.
- A preceding lifecycle or assignment action advanced its version.
- A background workflow changed related state before your submission.
Optimistic concurrency compares the version you opened with the current persisted version. A mismatch rejects the whole update instead of silently overwriting newer work.
Resolution steps
- Preserve any unsaved text outside the form when the page does not explicitly retain it.
- Refresh or reload the record using the page's normal control.
- Review the latest values, status, assignment, revision history, and allowed actions.
- Compare your intended change with the newer change.
- Reapply only the changes that are still correct.
- Submit once using the newly loaded record version.
What not to do
- Do not repeatedly submit the stale form.
- Do not use browser back/forward state as if it were the latest record.
- Do not create a duplicate record to avoid reconciling changes.
- Do not overwrite a colleague's update without reviewing it.
When to contact an owner or administrator
Contact the record owner or responsible manager when two intended changes conflict and a quality decision is needed. An administrator should not bypass version control; they can help coordinate which change is official.
“This transition is no longer valid”
Likely causes, in safe-check order
- The record moved to another lifecycle state after the page loaded.
- A required dependency appeared, such as an open calibration event or requirement.
- An out-of-tolerance investigation now blocks equipment restoration.
- The action requires a reason, retirement date, certificate, or other prerequisite.
- Your assignment or effective permission changed.
Resolution steps
- Reload the record and read its current status.
- Review the available actions rather than repeating the former action.
- Read the conflict message for the blocking dependency.
- Complete or resolve the underlying workflow through its controlled action.
- Retry only if the refreshed state still offers the intended transition.
What not to do
- Do not change unrelated status or evidence to force the transition.
- Do not archive, cancel, void, or retire dependencies merely to remove an error.
- Do not ask another user to bypass separation-of-duties checks.
When to contact an owner or administrator
Contact them when the dependency needs reassignment, permission review, or a quality decision. Use the responsible quality workflow for investigation, approval, retirement, or archival decisions.
“Refresh the structure and try again”
Likely causes, in safe-check order
- A site or location was edited, moved, activated, deactivated, or archived after you loaded it.
- A location's parent or descendants now make the requested action invalid.
- The selected client, site, or parent version is stale.
- The relationship is no longer active or operationally available.
Resolution steps
- Refresh Sites and locations.
- Reopen the intended site and expand the current location tree.
- Review the target, its parent, and its descendants.
- Reapply the change only if it remains structurally correct.
- For a missing option after refresh, follow Troubleshoot unavailable selections.
What not to do
- Do not create a duplicate location or site.
- Do not move descendants merely to force a parent archival.
- Do not submit a relationship identifier copied from another organisation.
When to contact an owner or administrator
Contact a structure manager when the current hierarchy needs an agreed operational change or you lack the required update, move, status, or archive permission.
An equipment movement is rejected
Likely causes, in safe-check order
- The equipment placement changed after you opened the assignment form.
- The selected effective time is in the future.
- The effective time equals or precedes the current deployment start.
- The selected site or location became inactive or unavailable.
- The equipment is retired or archived in the ordinary interface.
Resolution steps
- Refresh the equipment record and review its current assignment and deployment timeline.
- Confirm the actual movement time and its UTC interpretation.
- Ensure it is strictly later than the current interval start and not in the future.
- Reload destination and responsible-member selections.
- Submit the movement once with the current equipment version.
What not to do
- Do not invent a later timestamp merely to pass validation.
- Do not alter or hide the previous placement.
- Do not register another equipment record for the same physical asset.
- Do not use retirement, archival, or a false rotation movement as conflict recovery.
When to contact an owner or administrator
Contact the equipment or quality manager when the historical movement time conflicts with the current timeline and requires a controlled data decision. The ordinary assignment workflow does not insert a movement into the middle of existing history.
A conflict repeats after a fresh reload
Resolution steps
- Stop retrying and capture the exact visible message.
- Confirm the organisation, record identifier, current status, and approximate time.
- If shown, retain the error Reference.
- Ask an owner or administrator to confirm your membership, assignment, and the current domain state.
- If they confirm the action should succeed, contact the service operator with the safe diagnostic details.
Do not include passwords, access tokens, certificate contents, private evidence, or unrestricted audit narratives in a support request.