# Department Membership Architecture Decision

## Decision

**Users may belong to multiple departments** within the same company.

## Evidence

- Pivot table `department_user` enforces uniqueness on `(department_id, user_id)` only — not on `user_id` alone.
- `is_primary` marks one primary department per user; `DepartmentMembershipService` clears other primaries when a new primary is set.
- A user can hold different roles per department (e.g. department head in Support, agent in IT).

## Scoping implications

| Role | Scope |
|------|--------|
| Super Admin | All companies and departments |
| Company Admin | All departments in own company |
| Department Head | Managed department(s) only via `managedDepartmentIds()` |
| Normal User | Own tickets + department portal access |

Department heads **cannot** move users between departments or create other heads. Super admins and company admins retain those capabilities.

## Enforcement layers

1. **Pivot flags** — `is_department_head` / `is_manager` on `department_user`
2. **Services** — `UserAdminService`, `TicketVisibilityService`, `AssignableUserService`
3. **Policies** — department-scoped authorization on users, tickets, categories, SLA, templates
4. **Controllers** — explicit membership checks (e.g. `DepartmentSupportController`, ticket statistics)

This document records the existing architecture; no schema change was required for the enterprise readiness sprint.