Offer work to a security role and reserve it by claim

Purpose

Work can wait for an eligible role holder without creating another team queue.

How It Works

A service or API client creates an unassigned task with a candidate role. A holder asks for the tasks offered to their roles. The offered list excludes queued and already held work. Claim asks Platform to verify the claimant’s role holding. The row remains protected while that decision and assignment occur. A competing claimant receives the winning holder’s identity. Release keeps the role available for another claim. Queued tasks follow queue claim behavior even if they also name a role. The console does not yet expose an offered-work view. The product should resolve invalid role references and the difference between offered-list eligibility and claim eligibility.

Relationships

Task assignment supplies shared assignment and release behavior.
Workflow task actions create and reoffer role-directed work.
Platform security answers role membership for claims.

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: Role-directed workOne successful role claimantOffers restored by release
Surfaces: api
Preconditions: Platform can evaluate holdings of the candidate role in this workspace.
Intent sources: Andrew 2026-10-18 (role claim), recorded at services-crm:docs/workstreams/crm-tasks-role-claim.md

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.read`	api	tenant
`crm.tasks.update`	api	tenant

Business Rules

12 rules, 10 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	A new task can be offered by custom role identifier or built-in role key, but cannot be created both assigned to a person and offered to a role. origin: Andrew 2026-10-18 (role claim), recorded at services-crm:docs/workstreams/crm-tasks-role-claim.md no proof recorded yet	validation	service, database	test services-crm:modules/tasks/tests/integration/services/persistence/tasks.role-claim.integration.spec.js#refuses a create naming both an assignee and a role, naming the field, and writes nothing
`02`must prove Proposed	Claiming an unqueued role offer requires Platform to confirm the caller holds that role for the workspace; a non-holder receives Forbidden and leaves the offer unchanged. origin: Andrew 2026-10-18 (role claim), recorded at services-crm:docs/workstreams/crm-tasks-role-claim.md no proof recorded yet	permission	service	test services-crm:modules/tasks/tests/integration/services/persistence/tasks.role-claim.integration.spec.js#is refused 403 with the code task_claim_not_role_holder, and the task stays offered
`03`must prove Proposed	Concurrent role-holder claims produce one winner and conflicts naming that winner for later claimants. origin: Andrew 2026-10-18 (role claim), recorded at services-crm:docs/workstreams/crm-tasks-role-claim.md no proof recorded yet	invariant	service	test services-crm:modules/tasks/tests/integration/services/persistence/tasks.concurrency.integration.spec.js#refuses the other two 409 with the code task_claimed_by_other
`04`must prove Proposed	Claim preserves the candidate role, and release makes the task available to that role again. origin: Andrew 2026-10-18 (role claim), recorded at services-crm:docs/workstreams/crm-tasks-role-claim.md no proof recorded yet	policy	service	test services-crm:modules/tasks/tests/integration/services/persistence/tasks.role-claim.integration.spec.js#keeps the candidate role, so the task is offered again
`05`must prove Proposed	Reassignment to a different person clears the role offer, while removing the current holder retains it. no proof recorded yet	policy	service	test services-crm:modules/tasks/tests/integration/services/persistence/tasks.role-claim.integration.spec.js#clears the role when the task is given to somebody other than its holder
`06` Proposed	Queued tasks use queue claim rules regardless of any candidate role, so a task updater need not hold that role to claim them.	policy	service	test services-crm:modules/tasks/tests/integration/services/persistence/tasks.role-claim.integration.spec.js#is claimed through its queue, as every queued task is, by a user who does not hold the role
`07`must prove Proposed	The offered list returns unassigned open tasks outside queues for the user’s roles, ordered oldest first and paged with a maximum of 200 items. no proof recorded yet	policy	api, service	test services-crm:modules/tasks/tests/integration/services/persistence/tasks.queries.integration.spec.js#answers the three tasks offered to the user’s roles, oldest first, then by id
`08` Proposed	Ordinary task replacement preserves the candidate role.	policy	service	test services-crm:modules/tasks/tests/integration/services/persistence/tasks.role-claim.integration.spec.js#keeps the role a replacement leaves out, since it is create-only
`09`must prove Proposed	The console has no role-offer creation control or offered-to-me task view. no proof recorded yet	policy	console	unknown FND-CRM-ACT-010
`10`must prove Proposed	Role-offer creation checks reference syntax without verifying that the role exists for the customer. no proof recorded yet	validation	service	observed services-crm:modules/tasks/services/persistence/tasks.ts:candidateRoleAsWritten
`11`must prove Proposed	Offered-task listing omits an active-user check, allowing a service to obtain offers for a user Platform would prevent from claiming. no proof recorded yet	policy	service	documented services-crm:docs/workstreams/crm-tasks-role-claim.md#2. Should "offered to me" read the user's status?
`12`must prove Proposed	Role claims pass no related-record resource and therefore use workspace-wide or customer-wide role holdings. no proof recorded yet	permission	service	observed services-crm:modules/tasks/services/persistence/tasks.ts:holdsRole

Scenarios

Id	Given	When	Then	Provenance
`01`	An unqueued review task is offered to Reviewers.	Let a reviewer and a non-reviewer attempt claims.	The reviewer can claim, while the non-holder is forbidden.	test services-crm:modules/tasks/tests/e2e/tasks.e2e.spec.js#gives the task to the first holder to claim it, keeping the role

Edge Cases

Id	Given	When	Then	Provenance
`02`	A person holds the candidate role only in a different workspace.	Attempt to claim the offered task.	Platform membership evaluation rejects the claim.	test services-crm:modules/tasks/tests/integration/services/persistence/tasks.role-claim.integration.spec.js#is refused when the role is held only in another tenant

Planning

Offer work to a security role and reserve it by claim ​

Purpose ​

How It Works ​

Relationships ​