# ADR-007: Dual Tenant Membership Tables (Core vs Identity)

| Field | Value |
| --- | --- |
| Status | Accepted |
| Date | 2026-01-01 |
| Deciders | Platform Architecture |
| Supersedes | — |
| Superseded by | — |

## Context

Identity & Access introduced a simple `tenant_memberships` table for SSO membership listing. Workspace onboarding later required richer operational roles (`tenant_owner`, editor, viewer, owner flags, lifecycle). Merging into one DB would violate database-per-service.

## Decision

Keep two distinct tables named `tenant_memberships`:

1. `core_platform_db.tenant_memberships` — source of truth for workspace roles, ownership, and onboarding authorization
2. `identity_access_db.tenant_memberships` — SSO/identity-layer membership listing

No direct FK or sync between databases. Operational authorization uses Core.

## Consequences

### Positive

- Respects service boundaries
- Allows Identity and Core to evolve independently

### Negative

- Naming collision risk; docs must always qualify the database
- Possible temporary divergence until sync events exist

## Alternatives Considered

1. Move all membership to Identity and call Identity for every authz check
2. Drop Identity memberships and use Core only

## Related Documents

- [Multi-Tenant Architecture](../multi-tenant-architecture.md)
- [Authorization Architecture](../authorization-architecture.md)
- [Database Schema](../../reference/database-schema.md)
- [Glossary](../../glossary.md)