---
id: add-account-deactivation
name: Add Account Deactivation Mechanism
status: completed
depends_on: []
scope: narrow
risk: low
impact: component
level: implementation
---

## Description

W02: The `accounts` table has no `enabled`/`suspended` column. Combined with `organizations.ownerId → RESTRICT`, an org owner's account cannot be deleted, and there's no way to deactivate when an employee leaves. Other tables (`api_keys`, `clients`) already have `enabled` columns — add consistency.

Add a `status` enum column (`active`/`suspended`/`deactivated`) to the `accounts` table spec. Document how deactivation interacts with cascade constraints and active sessions.

## Decision (D5)

Use a `status` enum (`active` | `suspended` | `deactivated`), not a boolean. More extensible — allows distinguishing admin-suspended from user-deactivated in the future. This is especially important because RESTRICT cascade on audit_logs.ownerId means accounts with audit entries can never be hard-deleted; deactivation is the path forward.

## Acceptance Criteria

- [ ] `identity.md` accounts table includes `status` pgEnum (`active`/`suspended`/`deactivated`) with NOT NULL default `active`
- [ ] Interaction with cascade constraints documented (e.g., deactivated accounts can still own orgs but cannot authenticate)
- [ ] `table-reference.md` updated with the new column
- [ ] Consistency with `api_keys.enabled` and `clients.enabled` patterns noted

## References

- docs/reviews/storage-architecture-review-2026-04-21.md#W02
- docs/decisions/storage-spec-phase1-resolutions.md#D5
- docs/architecture/storage/identity.md (accounts table)

## Notes

> To be filled by implementation agent

## Summary

> To be filled on completion