Message recipient

Purpose

TBD by human

Identity & key fields

• Primary key: id (uuid, default gen_random_uuid()).
• messageId (uuid, NOT NULL, FK → notifications.message.id, on-delete cascade).
• customerId (uuid, NOT NULL, FK → companies.company_customer.id, on-delete cascade).
• notificationId (nullable uuid, FK → notifications.notification.id, on-delete set null) — link to the user-side notification, used to read readAt.
• createdAt (timestamp, NOT NULL).

business meaning: TBD by human

Invariants

• messageId, customerId ON DELETE CASCADE; notificationId ON DELETE SET NULL (enforced in tktspace-backend/libs/shared/data-access-db/src/lib/schema/notifications.schema.ts).
• messageId, customerId NOT NULL (enforced in tktspace-backend/libs/shared/data-access-db/src/lib/schema/notifications.schema.ts).

business invariants: TBD by human

Lifecycle

No status column — read status is tracked on the linked Notification.

Relationships

• Message (ENT-024) — messageId → notifications.message.id, on-delete cascade. N:1.
• Company customer (ENT-017) — customerId → companies.company_customer.id, on-delete cascade. N:1.
• Notification (ENT-026) — notificationId → notifications.notification.id, on-delete set null. N:1, optional.

API surfaces

Surface	Exposed	Notes
client	no — read status surfaces only via the Notification	—
business	inferred yes — listed under broadcast delivery reports; no dedicated DTO visible in audit-time business OpenAPI extract	Swagger UI
super-admin	no	—

Known gotchas / open questions

• notificationId is nullable — message recipients may exist without a user-side notification (e.g. when customer has no platform user / push channels disabled).
• OPEN: is there a UNIQUE on (messageId, customerId) to prevent duplicate deliveries? Not enforced at DB level.