# Resolve concurrent edits

Strive checks revisions for operations that must not overwrite newer work. A conflict means the item no longer matches the version used to prepare your change.

## Recover an edit

1. Preserve the intended changes in a local note if the form lets you inspect them safely.
2. Reload or fetch the item's current state.
3. Compare the new values with what you meant to change.
4. Reapply only the still-appropriate changes and submit again.
5. Verify the resulting saved version.

Do not repeatedly submit the stale form. A conflict is a request to reconcile, not evidence that the product needs a forced overwrite.

## Common conflict surfaces

App parameters, definitions, workflow publication and restoration, sharing, review edits and decisions, managed document replacement, extension lifecycle, and provider administration can have revision checks. Storage mutations can also refuse a changed source revision.

A pending Assistant card can be superseded when the underlying item changes. Ask for a fresh card. An app release publication can refuse when its source changed during capture; inspect the draft and publish the version you actually intend.

## A retry identity is different

Some operations also retain a request identity to recognise an exact retry. Repeating the same request can return its original outcome. Changing the request while reusing its old identity is a different conflict. The product's explicit same-request Retry preserves the original operation; a genuinely changed request needs a new operation.

For an interrupted write, establish the original result before creating that new operation. See [uncertain outcomes](/docs/troubleshooting/uncertain-outcomes).