# ADR-012: Independent Enterprise Communication Platform

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

## Context

Business modules (CRM, Loyalty, Restaurant, etc.) need SMS and future channels. Putting providers inside each module would duplicate credentials, break failover consistency, and couple tenants to modules they may not subscribe to.

Core already sends auth OTP via Payamak — that auth path stays separate for now, but platform messaging must be a shared infrastructure service.

## Decision

1. Introduce `communication-service` with sole ownership of `communication_db` (port 8005).
2. All outbound messaging (SMS first; email/push/social/voice later) goes through this service’s APIs and events.
3. Provider adapters live only inside Communication.
4. Dynamic contact sources resolve contacts via remote APIs — never copy business-module rows.
5. Tenants may activate Communication independently of other business modules.
6. Failures are tracked asynchronously; they must not abort calling business transactions.

## Consequences

### Positive

- Single provider registry, failover, templates, OTP, audit, and monitoring
- Clear module boundary for CRM `CommunicationProvider` contract fulfillment
- Extensible channel model without rewriting consumers

### Negative

- Additional deployable service and database
- Eventual consistency for delivery status

### Neutral

- Core auth OTP may later hand off to Communication when explicitly migrated

## Alternatives Considered

1. Expand `sms_panel` / `notification` scaffolds separately — rejected; unified Communication owns multi-channel routing.
2. Keep providers in each business module — rejected; violates independence and DRY.

## Related Documents

- [communication-phase-8.md](../../communication-phase-8.md)
- [Module Registry](../../module-registry.md)
- [ADR-001](ADR-001.md)
- [Module Boundaries](../module-boundaries.md)
