# Task L.1: CRM Multi-Role User Assignment

## Summary

Task L.1 extends the CRM authorization foundation so one user can hold multiple CRM role assignments inside the same organization.

## Implemented

- Added `crm_user_role_assignments` schema for CRM-specific authorization rows
- Added assignment permissions:
  - `crm.role.assignment.read`
  - `crm.role.assignment.create`
  - `crm.role.assignment.update`
  - `crm.role.assignment.delete`
  - `crm.role.assignment.manage`
- Added lazy compatibility backfill from `memberships.businessRole` into CRM role assignments
- Updated CRM access resolution to:
  - union permissions across all active assignments
  - union branch/product scope across assignments
  - choose the most permissive ownership scope
  - choose the highest approval authority
  - use primary role for display only
- Added `CRM Settings > User Role Assignments`
- Added assignment API routes:
  - `GET /api/crm/settings/user-role-assignments`
  - `POST /api/crm/settings/user-role-assignments`
  - `PATCH /api/crm/settings/user-role-assignments/[id]`
  - `DELETE /api/crm/settings/user-role-assignments/[id]`
- Added audit logging for `crm_user_role_assignment`
- Added ADR `0014-crm-multi-role-user-assignment`

## Compatibility

- `memberships.businessRole` remains in place
- when no active CRM role assignment exists, resolver still falls back safely
- when role assignments exist, CRM authorization no longer treats `memberships.businessRole` as the primary source

## Verification

- Run: `npx tsc --noEmit`

## Remaining Risks

- user-creation and user-edit flows still center around legacy `memberships.businessRole`
- some CRM modules beyond the current resolver consumers may still need deeper scenario verification with mixed-role fixtures
- a dedicated one-shot operational migration script can still be useful even though lazy backfill is active