Sign in

Synchronize operational changes between users with the same conversation open

Two users who have the same conversation open see each other's status, tag and assignment changes live, and a stale write is rejected rather than silently overwritten.

When this happens: One user changes the conversation's status, tags, or assignment while the other has it open.

Step by step

  1. 1

    Operator A adds the tag Billing question to the open conversation.

    Persists the tag, advances the conversation's concurrency token, and pushes the update to everyone with the conversation open, in addition to the tenant-wide list refresh.

  2. 2

    Operator B, who has the same conversation open, sees the Billing question tag appear without refreshing.

  3. 3

    Operator B, working from the state they last fetched, changes the status to Waiting for Customer and saves.

    Accepts the write, since the concurrency token is still current, applies it, and pushes the update to both operators.

Other paths

Join on open

Opening a conversation joins its live-update group, checked against EasyCrm.Conversations and the joining your visibility scope.

If something goes wrong

Concurrent conflicting write

Operator A and Operator B both act on the conversation within the same short window, and Operator B's request is based on state that is no longer current because Operator A's write landed first. System rejects Operator B's write with the standard concurrency-conflict error; the client refetches the current state and lets Operator B retry.

Good to know

  • The conversation's row-version concurrency token guards every mutating action.
  • The per-conversation live-update group carries changes for anyone who has the conversation open, independent of the tenant-wide list refresh.