---
id: ADR-CRM-ACT-009
title: Workflow task requests use service invocation and current-state repeat handling
product_area: crm
module: activities-tasks
revision: 1
status: proposed
design_intent: proposed
source_sha:
  services-crm: a8d1364f1dd44b723bb5f9acba12f983e9ec8d69
  react-console: baf6dae382d6f41dce976c7f848667ccc37e076f
decision: >-
  Expose one directly invoked task service dispatcher, deduplicating creation by a
  retained workflow-origin reference and handling later commands according to current task
  state.
constrains:
  - SVC-CRM-ACT-tasks
  - WF-CRM-ACT-005
  - DOM-CRM-ACT-003
origin: >-
  Platform application processes and workflow actions design, chapter 07 §4 and decision
  D-09, as recorded in services-crm docs/migrations/task-management/README.md §12 (WA-3a,
  2026-10-18).
alternatives:
  - option: Create a separate HTTP endpoint for each workflow action.
    why_not: >-
      The local caller boundary already resides in service invocation and does not require
      an HTTP surface.
  - option: Persist a delivery ledger for every later workflow command.
    why_not: >-
      That would define repeat behavior against previous deliveries rather than the task’s
      current state and requires a separately chosen product policy.
consequences:
  - >-
    Repeated creation returns the task for the retained action reference and indicates
    whether this request inserted it.
  - >-
    After reopening, another completion delivery can complete the task again; this is
    observed behavior without approval of every repeated effect.
  - >-
    CRM returns coded refusals, but the executor’s recording of unapplied actions remains
    external proof.
  - >-
    Service writes attribute the service principal, with the originating user carried as
    request provenance.
supersedes: []
evidence:
  - >-
    services-crm at a8d1364f: aws/crm.service-functions.ts;
    modules/tasks/aws/api/tasks-service.routes.ts, tasks-service.schemas.ts;
    services/workflow-actions/task-service-operations.ts;
    docs/migrations/task-management/README.md §12.
---

# Workflow task requests use service invocation and current-state repeat handling

## Context

Workflow callers need a bounded way to act on task work. Their external delivery and retry policy is outside the inspected CRM implementation.

## Decision

The service dispatcher validates a declared operation set. Creation carries an action-origin reference; later changed requests use row serialization and already-satisfied checks. Workflow creation omits queue, status and client record identifier inputs.

## Alternatives Considered

The structured alternatives describe concrete competing designs and their tradeoffs. Where the origin records an existing ruling, it remains the authority; an observed implementation does not establish Product’s rejection of every alternative.

## Consequences

Creation deduplication is limited to retained origin references. Later commands do not promise exactly-once effects across intervening changes, and end-to-end executor behavior remains unverified.