Assign shared work and claim it from a queue

Purpose

Teams route tasks and reserve shared work for one person at a time.

How It Works

A coordinator assigns work to a colleague or places it in a queue. Queue entry gives the task an arrival position. A worker can claim an unassigned open task from that queue. Simultaneous claims leave one successful holder. Release removes the holder without moving the task to the back. Moving the task to another queue establishes a new arrival position there. Closed work must be reopened before assignment changes. Assignment checks user identifier syntax but does not yet confirm workspace eligibility. The product should implement the recorded eligibility requirement. Inactive queues continue accepting work until Product settles their retirement behavior.

Relationships

Task configuration defines the available queues.
The Tasks screen presents queue views and claim controls.
Overdue attention uses queue responsibility for unclaimed work.

Show evidence (sources, provenance, origins, pinned commits)

The Formal Contract

The narrative above explains; the sections below are authoritative — the rules, scenarios and tests this document binds.

Outcomes: Attributable assignmentOne successful claimant for queued workQueue position retained on release
Surfaces: consoleapi
Preconditions: The task remains open and permits updates.
Intent sources: services-crm:docs/milestones/CRM-M8-activities-and-tasks.md#E-10

Controls

23 controls apply, from the corpus control catalogue.

TC-AZ-001 TC-AZ-002 TC-AZ-003 TC-AZ-004 TC-AZ-006 TC-DAT-001 TC-DAT-002 TC-DAT-003 TC-LOG-001 TC-LOG-002 TC-LOG-003 TC-LOG-004 TC-LOG-005 TC-PI-001 TC-PI-002 TC-PI-003 TC-PI-005 TC-PRV-001 TC-PRV-002 TC-TEN-001 TC-TEN-002 TC-TEN-003 TC-TEN-004

Permissions

Key	Checked at	Scope
`crm.tasks.update`	api	tenant
`crm.tasks.update`	console	tenant

Business Rules

13 rules, 11 to be proved before approval. A rule's product intent is derived from its origin: 0 confirmed by a product decision, the rest inheriting this capability's proposed.

Id	Rule	Kind	Enforced at	Provenance
`01`must prove Proposed	Assignment records the assigning actor and time, preserves the original stamps when the holder is unchanged, and clears them when assignment is removed. no proof recorded yet	invariant	service, database	test services-crm:modules/tasks/tests/e2e/tasks.e2e.spec.js#stamps who holds the task, who gave it to them and when
`02`must prove Proposed	A task may have a holder, queue, both or neither, and queue membership carries its entry time for arrival ordering. no proof recorded yet	invariant	service, database	test services-crm:modules/tasks/tests/integration/db/tasks.table.integration.spec.js#refuses a queue with no moment, so no task sits in a queue in no order
`03`must prove Proposed	Changing queues records a new entry time, while edits within the same queue retain the earlier place. no proof recorded yet	calculation	service	test services-crm:modules/tasks/tests/integration/services/persistence/tasks.integration.spec.js#moves a task to another queue and re-stamps when it entered, so it joins the back of that one
`04`must prove Proposed	The assignment action can change the holder and queue together but rejects closed tasks. no proof recorded yet	policy	service	test services-crm:modules/tasks/tests/integration/services/persistence/tasks.integration.spec.js#refuses an assignment of a closed task, asking for the reopen first
`05`must prove Proposed	Assignments reject stale versions when one is supplied; without a version, the last assignment takes effect. no proof recorded yet	validation	api, service	test services-crm:modules/tasks/tests/e2e/tasks.e2e.spec.js#answers 409 for an assignment at a version the task has moved past
`06`must prove Proposed	A holder must have a valid Rhythm user identifier, and a service principal cannot hold work. no proof recorded yet	validation	api, service, database	test services-crm:modules/tasks/tests/e2e/tasks.e2e.spec.js#answers 400 for an assignee that is not a Rhythm user id
`07`must prove Proposed	The product should check workspace membership and task eligibility with Platform; assignment currently validates identifier syntax only. origin: services-crm:docs/milestones/CRM-M8-activities-and-tasks.md#E-10 no proof recorded yet	validation	service	test react-console:acceptance/crm/playwright/journeys/cross-application/CRM-ACC-0711.spec.ts#CRM-ACC-0711
`08`must prove Proposed	A queued open task without a holder can be claimed, and simultaneous attempts produce one winner with the others informed of the holder. no proof recorded yet	invariant	service, database	test services-crm:modules/tasks/tests/integration/services/persistence/tasks.concurrency.integration.spec.js#lets exactly one of them have it
`09`must prove Proposed	An unqueued task with no role offer must be assigned; claims are rejected for closed tasks and full update locks. no proof recorded yet	validation	service	observed services-crm:modules/tasks/services/persistence/tasks.ts:claimTask
`10`must prove Proposed	Release clears the holder while preserving the queue position, is available to any caller with update authority, and rejects a task with no holder. no proof recorded yet	policy	service	test services-crm:modules/tasks/tests/integration/services/persistence/tasks.integration.spec.js#leaves the task in its queue, in the place it had: a release is not a re-queue
`11` Proposed	Claim requires a signed-in user, while release can be performed by an authorized service because it sets no new holder.	permission	service	test services-crm:modules/tasks/tests/integration/services/persistence/tasks.integration.spec.js#is refused a claim
`12`must prove Proposed	Inactive queues still permit task creation and claims. no proof recorded yet	policy	service	test react-console:acceptance/crm/playwright/journeys/cross-application/CRM-ACC-0710.spec.ts#CRM-ACC-0710
`13` Proposed	The console shows Claim for open unassigned queued work and Release for open assigned queued work, subject to task update permission.	permission	console	test react-console:lib/tasks/types.test.ts#is offered on an open task waiting unclaimed in a queue

Scenarios

Id	Given	When	Then	Provenance
`01`	Membership services has two waiting tasks.	Claim the earlier task, release it and claim it again.	Its queue entry position does not change.	test react-console:acceptance/crm/playwright/journeys/cross-application/CRM-ACC-0709.spec.ts#CRM-ACC-0709
`02`	Three workers target the same queued task.	Deliver their claims concurrently.	One worker becomes holder and the other attempts identify that holder.	test react-console:acceptance/crm/playwright/journeys/cross-application/CRM-ACC-0710.spec.ts#CRM-ACC-0710

Edge Cases

Id	Given	When	Then	Provenance
`03`	A valid-looking user reference belongs to another customer.	Assign a task to that reference.	Assignment succeeds despite selector exclusion, and no holder display name is resolved.	test react-console:acceptance/crm/playwright/journeys/cross-application/CRM-ACC-0711.spec.ts#CRM-ACC-0711

Planning

Assign shared work and claim it from a queue ​

Purpose ​

How It Works ​

Relationships ​