Issue with Optimistic Locking + “Save for Later” Preventing Other Users from Submitting Assignment

General
1

I am using optimistic locking across all my case types to allow multiple users to work on the same case/assignment concurrently.

Expected Behavior

  • Multiple users should be able to open and edit the same assignment.
  • When the first user submits, their changes should be committed.
  • If a second user submits after that, they should get a conflict error (expected optimistic locking behavior).

Current Issue

  • User A opens an assignment, makes changes, and clicks “Save for Later.”
  • After this:
    • The assignment appears to be locked by User A.
    • When User B tries to open or work on the same assignment, they get an error like: “This case has been modified/locked by another user.”
  • Because of this:
    • Other users cannot modify or submit the assignment.
    • This defeats the purpose of optimistic locking.

Requirement

  • “Save for Later” should not lock the assignment permanently.
  • Other users should still be able to:
    • Open the assignment
    • Make edits
    • Submit (with conflict handled at submit time)

Questions

  1. Why is “Save for Later” causing a lock, even under optimistic locking?
  2. Is there a way to prevent the assignment from being locked after saving?
  3. What configuration or approach allows:
    • Multiple users to edit
    • Locking/conflict only during submission

Any suggestions or best practices would be appreciated.

2

Ideally it shouldn’t. Wondering if you have any activities in the flow further down where locks are acquired and not released (release on commit unchecked in obj open)

3

Could you maybe check whether the Save for Later flow action is configured to not lock the case on the Security tab, and confirm whether the case is explicitly unlocked after save if needed.

4

“Save for Later” is not the same as a pure optimistic-concurrency edit session. Optimistic locking allows multiple users to work on the same case, but the conflict is detected at save or submit time. If the assignment remains locked after Save for Later, it usually means the case design, parent-lock settings, or custom post-save logic is still holding ownership of the assignment.

If the requirement is true concurrent editing, I would first review the case locking configuration and any parent/child lock behavior. The design should allow users to reopen and edit without preserving a persistent lock, and the conflict should be handled only at submit time.

In short, Save for Later should be treated as a draft/save action, not as the mechanism that enables parallel ownership of the same assignment.