Sign in

Pick up an unassigned conversation from the shared inbox

An operator claims an Unassigned conversation from the shared Inbox, becoming its responsible party. Because more than one operator can act on the same row at once, the first pick-up wins and the second is rejected cleanly.

When this happens: Operator clicks Pick up on an Unassigned conversation in the Inbox.

Step by step

  1. 1

    Open the Unassigned Inbox view and clicks *Pick up* on a WhatsApp conversation from *+373 69 …*.

    EasyCRM checks that ResponsiblePartyType is still Unassigned. Sets User, ResponsibleUserId = the operator, guarded by RowVersion. Writes AssignmentHistory with PickUp, Unassigned, ByUserId = the operator. Moves the conversation into the operator's *Mine* view for every connected viewer, without notifying the picking-up operator themselves.

Other paths

Re-click by the same operator

Click Pick up again on a conversation they already hold. EasyCRM returns success idempotently; no duplicate AssignmentHistory row is written.

If something goes wrong

Already claimed by another operator

If another operator already claimed the conversation a moment earlier. Rejects with EasyCrm:Routing:AlreadyAssigned. If both pick-ups reach step 3 within the same instant, the second RowVersion-guarded save fails; the concurrency exception is translated to the same EasyCrm:Routing:AlreadyAssigned code rather than the generic concurrency envelope. Sees Already picked up by [name] and the conversation disappears from their Unassigned view.

Pick-up disabled

RoutingSettings.AllowOperatorPickUp is off. The Pick Up button is not shown.

Good to know

  • Pick-up is race-safe — first request wins, the second gets a clean error, never a silent double-assignment. |
  • The race-safe pattern mirrors the existing lead-claim flow. |
  • An Unassigned conversation is scoped by visibility scope like any other — a user whose scope excludes it never sees the Pick Up option.