---
id: ADR-CRM-ACT-013
title: Configuration records use immutable configuration identifiers and atomic reorder
product_area: crm
module: activities-tasks
revision: 1
status: proposed
design_intent: confirmed
source_sha:
  services-crm: a8d1364f1dd44b723bb5f9acba12f983e9ec8d69
  react-console: baf6dae382d6f41dce976c7f848667ccc37e076f
decision: >-
  Keep immutable, grammar-constrained configuration names for activity types, task types
  and queues, and use their complete-list transactional reorder APIs as required by the
  recorded policy.
constrains:
  - DOM-CRM-ACT-001
  - DOM-CRM-ACT-003
  - SVC-CRM-ACT-activities
  - SVC-CRM-ACT-tasks
  - SCR-CRM-ACT-007
  - SCR-CRM-ACT-008
  - SCR-CRM-ACT-009
origin: >-
  Andrew 2026-10-10 (configuration identifiers), recorded at services-crm
  modules/tasks/db/task-configurations.ts; the atomic reorder answers defect DEF-CRM-0722;
  D-08 requires that reorders are not blocked by unrelated locked records.
alternatives:
  - option: Identify configuration only with opaque generated record references.
    why_not: Stable baseline and import matching would need another name-to-reference mechanism.
  - option: Save each moved configuration record separately during reorder.
    why_not: >-
      Partial failure can commit only part of the requested ordering, as the current task
      configuration screens demonstrate.
consequences:
  - >-
    Baseline identifiers are stable across workspaces and support conflict-tolerant
    adoption.
  - >-
    Service reorder accepts the complete set, including unrelated locked records, and
    commits it as one change.
  - >-
    Task-category and queue screens still need alignment with the atomic reorder
    endpoints.
supersedes: []
evidence:
  - >-
    services-crm at a8d1364f: modules/tasks/db/task-configurations.ts;
    services/persistence/task-configurations.ts;
    modules/activities/services/persistence/activity-types.ts.
  - >-
    react-console at baf6dae3: lib/configuration/crm-collection.ts (atomicDisplayOrder);
    lib/configuration/task-types.ts and task-queues.ts (orderedCollection).
---

# Configuration records use immutable configuration identifiers and atomic reorder

## Context

Configuration is shared by baselines, imports, integrations and interactive selection. Its identity needs to remain stable when its display name changes.

## Decision

The cited configuration and ordering decisions remain authoritative. Creation uses a supplied configuration name or derives it from the display name. Database grammar and local uniqueness apply; subsequent renaming retains identity.

## 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

Activity configuration already uses the atomic console order adapter. Task configuration currently uses separate saves, leaving a recorded implementation difference.