---
id: ADR-CRM-ACT-014
title: People and roles are Platform references without database keys
product_area: crm
module: activities-tasks
revision: 1
status: proposed
design_intent: proposed
source_sha:
  services-crm: a8d1364f1dd44b723bb5f9acba12f983e9ec8d69
  react-console: baf6dae382d6f41dce976c7f848667ccc37e076f
decision: >-
  Store user and candidate-role references without cross-area foreign keys, distinguish
  syntax checks from actual eligibility, and retain the planning requirement for Platform
  membership and task-eligibility validation during assignment.
constrains:
  - DOM-CRM-ACT-001
  - DOM-CRM-ACT-003
  - SVC-CRM-ACT-tasks
  - STATE-CRM-ACT-003
origin: >-
  Task management migration design §10 (form-only validation, because CRM cannot enumerate
  a workspace's users); ruling E-10 (CRM-M8, 2026-10-19, DEF-CRM-0709, answer A) asks for
  the Platform membership and eligibility check, recorded by FND-CRM-ACT-002.
alternatives:
  - option: Create CRM foreign keys into Platform user and role records.
    why_not: >-
      That would couple local persistence to authority-owned records and exceed the
      declared database boundary.
  - option: Treat valid reference syntax as permanent proof of eligibility.
    why_not: >-
      A correctly formed reference can still identify someone unable to act on work in the
      workspace.
consequences:
  - >-
    Current API assignment accepts user-reference syntax without the planned eligibility
    check.
  - Candidate-role syntax can be accepted even when no usable role exists.
  - >-
    Console user search is customer-scoped and does not prove the required
    workspace-membership or task-eligibility contract.
supersedes: []
evidence:
  - >-
    services-crm at a8d1364f: modules/tasks/db/tasks.table.ts (header);
    services/persistence/tasks.ts (assigneeAsWritten, candidateRoleAsWritten);
    modules/activities/db/activities.table.ts (owner);
    docs/migrations/task-management/README.md §10.
---

# People and roles are Platform references without database keys

## Context

User and role authority belongs to Platform, while CRM stores ownership and work-routing references. Local grammar does not establish that an actor can use the workspace.

## Decision

The cited planning ruling asks for assignment eligibility validation, and the current persistence path still performs syntax-only checks. Role-only claims separately consult current role holding. The two checks must not be conflated.

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

API-created routing can reference unavailable actors or roles. The pending assignment check remains an implementation requirement supported by its existing planning finding.