---
id: WF-CRM-ACT-008
title: Install and reset the baseline activity and task types
trigger: >-
  The workspace lifecycle invokes CRM participants for provisioning, verification,
  inventory, reset or purge.
product_area: crm
module: activities-tasks
revision: 1
status: draft
design_intent: proposed
implementation_evidence: partially-observed
inference: []
source_sha:
  services-crm: a8d1364f1dd44b723bb5f9acba12f983e9ec8d69
implements:
  - CAP-CRM-ACT-009
  - CAP-CRM-ACT-016
moves:
  - STATE-CRM-ACT-005
crosses:
  - SVC-CRM-ACT-activities
  - SVC-CRM-ACT-tasks
idempotency: >-
  The seed ledger records applied baseline sets, and inserts adopt matching existing
  configuration without overwriting local changes. Repeated provisioning skips recorded
  sets; conflicts can also adopt existing records. This does not prove external lifecycle
  retry policy.
concurrency: >-
  CRM declares participant dependencies and conflict-tolerant seed insertion. The external
  lifecycle planner controls execution order and retries; these repositories do not
  independently prove that orchestration.
hops:
  - 'n': 1
    actor_or_service: External workspace lifecycle planner
    action: >-
      Have the external lifecycle orchestrator invoke registered CRM participants in their
      declared dependency order.
    anchor: 'services-crm:modules/activities/README.md#What Platform must add'
    seam: sync
    on_failure: >-
      CRM reports a participant failure; external retry and recovery behavior requires
      proof.
    left_inconsistent: >-
      An externally unregistered participant would be omitted, but these pins do not
      establish that registration is absent.
    observer: The external lifecycle run owns orchestration visibility.
    provenance: documented
    source: 'services-crm:modules/activities/README.md#What Platform must add'
  - 'n': 2
    actor_or_service: Task baseline participant
    action: >-
      Apply the General, Follow-up, Call, Email and Meeting task-type baseline without
      creating queues.
    anchor: >-
      services-crm:modules/tenant-lifecycle/services/participants/tasks-participant.ts:CRM_TASKS_PARTICIPANT
    seam: sync
    on_failure: Report a failed seed step to the lifecycle caller.
    left_inconsistent: Previously committed seed sets remain applied.
    observer: The seed ledger and lifecycle caller expose results.
    provenance: test
    source: >-
      services-crm:modules/tasks/tests/integration/services/persistence/task-types.integration.spec.js#adopts
      a record the tenant edited, which is what makes a seed a starting point
  - 'n': 3
    actor_or_service: Activity baseline participant
    action: >-
      Apply the seven baseline activity categories with their fixed codes and initial
      results.
    anchor: >-
      services-crm:modules/tenant-lifecycle/services/participants/activities-participant.ts:CRM_ACTIVITIES_PARTICIPANT
    seam: sync
    on_failure: Report a failed seed step to the lifecycle caller.
    left_inconsistent: Previously committed seed sets remain applied.
    observer: The seed ledger and lifecycle caller expose results.
    provenance: test
    source: >-
      services-crm:modules/activities/tests/integration/services/persistence/activity-types.integration.spec.js#adopts
      a type the tenant already has under that id, leaving it as the tenant made it
  - 'n': 4
    actor_or_service: CRM reset and purge participants
    action: >-
      Perform child-first record cleanup; reset retains baseline type identifiers and
      reapplies defaults, while purge removes the module’s records and declared event
      data.
    anchor: >-
      services-crm:modules/tenant-lifecycle/services/participants/tasks-participant.ts:CRM_TASKS_PARTICIPANT
    seam: sync
    on_failure: Report participant failure for externally controlled recovery.
    left_inconsistent: >-
      A multi-step lifecycle can retain a partially cleaned workspace until recovery; its
      timing is unverified.
    observer: The external lifecycle run receives the result.
    provenance: observed
    source: >-
      services-crm:modules/tenant-lifecycle/services/participants/tasks-participant.ts:CRM_TASKS_PARTICIPANT
branches:
  - >-
    Reconciliation for existing workspaces belongs to Platform under the recorded
    lifecycle decision.
waits: []
evidence:
  - >-
    services-crm at a8d1364f:
    modules/tenant-lifecycle/services/participants/activities-participant.ts,
    activity-type-seeds.ts, tasks-participant.ts, task-type-seeds.ts;
    modules/activities/README.md (What Platform must add);
    docs/migrations/activities/README.md §3; docs/migrations/task-management/README.md §6;
    docs/milestones/CRM-M8-activities-and-tasks.md (D-48).
controls: [TC-AZ-001, TC-AZ-002, TC-AZ-003, TC-AZ-004, TC-AZ-005, TC-AZ-006, TC-DAT-001, TC-DAT-003, TC-DAT-004, TC-IAM-001, TC-IAM-005, TC-IAM-006, 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-TEN-001, TC-TEN-002, TC-TEN-003]
---

# Install and reset the baseline activity and task types

## What It Does

CRM declares baseline configuration and lifecycle participants so workspaces can start with usable activity and task categories. Seed adoption preserves local administration. Reset and purge have different retention goals and operate through their declared cleanup steps.

## The Flow

```mermaid
flowchart TD
  A[External lifecycle invokes registered CRM participants] --> B{Requested lifecycle phase?}
  B -->|Provision| C[Apply task baseline through seed ledger]
  C --> D[Apply activity baseline after declared dependencies]
  B -->|Reset| E[Clean records child first and retain baseline identities]
  E --> F[Reapply baseline seed sets]
  B -->|Purge| G[Remove declared module and event data]
  B -->|Verify or inventory| H[Return participant checks or inventory]
  D --> I[Report local participant result]
  F --> I
  G --> I
  H --> I
```

The numbered hops specify the request, persistence and integration boundaries in order. Each hop identifies its evidence anchor, synchronization seam and observable failure outcome. Branches distinguish optional and delegated paths.

## When Something Fails

A participant reports failed steps to its lifecycle caller. Earlier committed steps can remain applied, with seed-ledger behavior supporting repeat provisioning. External participant registration and orchestration recovery remain unverified rather than presumed missing.

## Open Design Questions

Platform must supply evidence of participant registration and reconciliation for existing workspaces before provisioning and cleanup readiness can be accepted.