MOD-CRM-ACT

Activities, Follow-ups and Task Work Design

How this module will be built: 43 design artifacts, by kind. Design makes the technical choices once, reviewably, and citable by everything they constrain.

27Draft
16Proposed

Domain Objects 3

State Models 5

Workflows 8

Service Contracts 2

Screen Contracts 9

Decision Records 16

ADR-CRM-ACT-001One activity is linked to every record it concernsProposed
ADR-CRM-ACT-002Activities and tasks carry no custom fieldsProposed
ADR-CRM-ACT-003Task closing is a dedicated action with its own recordProposed
ADR-CRM-ACT-004Read versions and creation recovery have operation-specific exceptionsProposed
ADR-CRM-ACT-005Replacement carries the complete payload; partial edits are patchesProposed
ADR-CRM-ACT-006A follow-up task commits with its activityProposed
ADR-CRM-ACT-007Workspace-wide lists are queries over datasets, not list routesProposed
ADR-CRM-ACT-008Role offers are decided by Platform's role holding at claim timeProposed
ADR-CRM-ACT-009Workflow task requests use service invocation and current-state repeat handlingProposed
ADR-CRM-ACT-010Overdue attention shares task transactions and uses conditional daily reconciliationProposed
ADR-CRM-ACT-011Activities and tasks outlive the records they concernProposed
ADR-CRM-ACT-012Activity history is written by the database at commit; tasks keep stamps onlyProposed
ADR-CRM-ACT-013Configuration records use immutable configuration identifiers and atomic reorderProposed
ADR-CRM-ACT-014People and roles are Platform references without database keysProposed
ADR-CRM-ACT-015No activities or tasks operation is published to Submissions yetProposed
ADR-CRM-ACT-016Activity files go through the shared record-asset pipelineProposed