Create workflow tasks once and repeat actions according to state

Purpose

Application processes delegate human work through a service contract with safe creation retries.

How It Works

Another registered Rhythm service invokes the task contract directly. It requests creation, closure, reassignment, redating or offered-work listing. Creation identifies the originating workflow step. Repeated and concurrent creation deliveries recover the task already associated with that step. Other actions compare the requested result with the task’s current state. If that result already holds, they return without another change. An intervening person-driven change can make a later delivery act again or be refused. CRM does not retain a delivery identity for those actions. Writes identify the service principal, with an originating person retained as provenance. External workflow executors and their response handling remain outside the examined source scope.

Relationships

Task recording and lifecycle own the resulting work and state.
Role offers route tasks to eligible claimants.
Platform integrations own workflow execution and delivery handling.

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: A single task for each creation stepRepeat responses based on task stateService attribution and explicit refusals
Surfaces: apijob
Preconditions: The caller is a registered service with invocation authority for the tasks service.
Intent sources: services-crm:docs/workstreams/wa-3a-tasks-action-link.md

Controls

29 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-IAM-001 TC-IAM-005 TC-IAM-006 TC-LOG-001 TC-LOG-002 TC-LOG-003 TC-LOG-004 TC-LOG-005 TC-MON-001 TC-MON-002 TC-PI-001 TC-PI-002 TC-PI-003 TC-PI-004 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.create`	service	tenant
`crm.tasks.update`	service	tenant

Business Rules

12 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	Only registered Rhythm services can invoke the tasks service directly; HTTP requests and unknown principals are refused. no proof recorded yet	permission	api, service	test services-crm:modules/tasks/tests/e2e/tasks-service.e2e.spec.js#answers 403 context_mismatch to a console caller reaching the route over HTTP, whatever its keys
`02`must prove Proposed	The service supports task creation, completion, cancellation, reassignment, role offers, due-day changes and offered-task listing. no proof recorded yet	policy	api, service	observed services-crm:modules/tasks/aws/api/tasks-service.schemas.ts:TASK_SERVICE_OPERATIONS
`03`must prove Proposed	A workflow creation reference is workspace-unique, so repeated or concurrent creates return one task and identify whether that delivery created it. no proof recorded yet	invariant	service, database	test services-crm:modules/tasks/tests/integration/services/workflow-actions/task-service-operations.integration.spec.js#answers the repeat with the same task
`04`must prove Proposed	Repeating completion, cancellation, reassignment or due-day changes returns the task unchanged when the requested state already holds. no proof recorded yet	invariant	service	test services-crm:modules/tasks/tests/integration/services/persistence/tasks.workflow-actions.integration.spec.js#answers a completed task as it is, writing nothing, when asked again idempotently
`05`must prove Proposed	Inapplicable actions return specific refusals for incompatible closing, closed-task reassignment or redating, and update locks. no proof recorded yet	validation	service	test services-crm:modules/tasks/tests/integration/services/workflow-actions/task-service-operations.integration.spec.js#names the refusal to complete a cancelled task task_closed_otherwise
`06`must prove Proposed	A task can be addressed by task reference, originating creation step or both, with disagreement between the two refused. no proof recorded yet	validation	service	test services-crm:modules/tasks/tests/integration/services/workflow-actions/task-service-operations.integration.spec.js#refuses an id and a run that name two different tasks (400), and changes neither
`07`must prove Proposed	A service request provides the holder once, through either supported user form or a role offer. no proof recorded yet	validation	api	test services-crm:modules/tasks/tests/e2e/tasks-service.e2e.spec.js#refuses a create naming its holder twice, assignee and assignee_user_id, 400
`08`must prove Proposed	Workflow creation cannot specify a queue, initial status or task identifier. no proof recorded yet	validation	api	observed services-crm:modules/tasks/aws/api/tasks-service.schemas.ts:createRequest
`09`must prove Proposed	A task’s cross-application subject requires both a record kind and a record reference. no proof recorded yet	validation	service, database	test services-crm:modules/tasks/tests/integration/services/persistence/tasks.workflow-actions.integration.spec.js#refuses an object with no record, naming the record, and writes nothing
`10`must prove Proposed	Service writes attribute record stamps to the service principal, retaining the originating person only as execution provenance. no proof recorded yet	invariant	service, database	test services-crm:modules/tasks/tests/integration/services/workflow-actions/task-service-operations.integration.spec.js#creates the task the action asked for, with the service principal as its creator and assigner
`11` Proposed	Services can assign and close tasks but cannot hold or claim them.	permission	service, database	test services-crm:modules/tasks/tests/integration/services/persistence/tasks.workflow-actions.integration.spec.js#refuses a service the claim of a queued task, because a claim makes the caller the assignee
`12`must prove Proposed	Non-create actions retain no delivery reference, so a repeat after an intervening change is evaluated anew against current task state. no proof recorded yet	invariant	service	observed services-crm:modules/tasks/services/workflow-actions/task-service-operations.ts:runTaskServiceOperation

Scenarios

Id	Given	When	Then	Provenance
`01`	A workflow creation step identifies a review task’s subject.	Deliver its create request twice.	Only one task is stored and the repeated answer reports no creation.	test services-crm:modules/tasks/tests/e2e/tasks-service.e2e.spec.js#answers the repeat 200 with the same task, unchanged, not created by it

Edge Cases

Id	Given	When	Then	Provenance
`02`	A person cancelled the workflow’s task.	Deliver a completion action.	The action reports incompatible closure and preserves Cancelled.	test services-crm:modules/tasks/tests/integration/services/workflow-actions/task-service-operations.integration.spec.js#refuses to complete a task a person cancelled (409), leaving it cancelled

Planning

Create workflow tasks once and repeat actions according to state ​

Purpose ​

How It Works ​

Relationships ​