The tables behind Client Collaboration Portal

The branded site config — one row per Account or Project tenant on the portal. Resolves the subdomain or vanity domain, the brand theme, the OAuth provider, and the active status. Every portal URL hits one portal site first.

Reusable theme presets — color palette, typography, and logo defaults — applied across one or many portal sites. Centralizes brand updates so a customer-rebrand does not require touching every site row.

Per-event branded email templates — invitation, document notification, approval request, status update, comment notification, inactive-user reminder, weekly digest. Subject + Body interpolate portal site + client user + payload variables at send time. Email templates are looked up by (PortalSite, EventType) at workflow runtime; if no portal site-specific template exists for the event, the system falls back to portal site default email template.

The external client user master — every person on the customer side who logs into the portal. Two-namespace separation from internal Users keeps the auth surfaces and audit logs clean.

Junction between portal sites and the internal Projects master — which Projects each portal site exposes to clients. One row per Project published on a Site.

Junction granting a client user visibility into one or more portal projects on a portal site. The portal-scope access pattern reads this table on every page render.

One-click email-to-portal tokens. Issued for invitation, document view, approval action, status-update view, and digest opens. Single-use, time-limited, server-side resolved — Token never appears in any UI.

A document published from an internal source system (workflow-dms, Project Billing Invoices, Project Management deliverables) to the portal. The publish record points at a file URL and tracks the audience scope, acknowledgment requirement, and lifecycle.

One row per client user × document share download event. The audit grain for “did the client open the deliverable” — feeds the client activities log and the engagement digest.

Junction between portal sites and the internal Projects master — which Projects each portal site exposes to clients. One row per Project published on a Site.

The external client user master — every person on the customer side who logs into the portal. Two-namespace separation from internal Users keeps the auth surfaces and audit logs clean.

One-click email-to-portal tokens. Issued for invitation, document view, approval action, status-update view, and digest opens. Single-use, time-limited, server-side resolved — Token never appears in any UI.

A request for a client decision — a deliverable sign-off, a change order, an invoice approval, a milestone confirmation. Routed to a named RequestedFromClient Client user; resolves into one or more ApprovalDecisions and triggers the source-record callback.

The decision capture line — who approved or rejected, when, with what comments and (optional) signature. Append-only; a re-decision writes a new line and stamps the prior as superseded.

One-click email-to-portal tokens. Issued for invitation, document view, approval action, status-update view, and digest opens. Single-use, time-limited, server-side resolved — Token never appears in any UI.

The external client user master — every person on the customer side who logs into the portal. Two-namespace separation from internal Users keeps the auth surfaces and audit logs clean.

Junction granting a client user visibility into one or more portal projects on a portal site. The portal-scope access pattern reads this table on every page render.

A published status update from the internal team to the client side of a Project. Carries Title + Body + Audience scope + publish metadata; fans out to subscribed client users via portal feed and email on publish.

The chronological feed of portal-relevant events shown to client users on the portal home — published documents, new status updates, approval requests, recent comments. One row per event per portal project.

The external client user master — every person on the customer side who logs into the portal. Two-namespace separation from internal Users keeps the auth surfaces and audit logs clean.

Junction granting a client user visibility into one or more portal projects on a portal site. The portal-scope access pattern reads this table on every page render.

Delivery receipts for branded notifications; providers report delivery independently of client actions.

Discussion threads on shared artifacts — a document share, an approval request, or a status update. One Comment is the root of one thread; replies live in comment replies.

Reply lines within a Comment thread — append-only chronological list. Mention captures handled inline in the body via @email syntax.

A document published from an internal source system (workflow-dms, Project Billing Invoices, Project Management deliverables) to the portal. The publish record points at a file URL and tracks the audience scope, acknowledgment requirement, and lifecycle.

A request for a client decision — a deliverable sign-off, a change order, an invoice approval, a milestone confirmation. Routed to a named RequestedFromClient Client user; resolves into one or more ApprovalDecisions and triggers the source-record callback.

A published status update from the internal team to the client side of a Project. Carries Title + Body + Audience scope + publish metadata; fans out to subscribed client users via portal feed and email on publish.

The audit log of every client-side action — login, document download, approval submit, comment posted, magic-link redeemed. Portal Manager + Account Manager + Admin only; never exposed to client users.

One row per client user × document share download event. The audit grain for “did the client open the deliverable” — feeds the client activities log and the engagement digest.

The decision capture line — who approved or rejected, when, with what comments and (optional) signature. Append-only; a re-decision writes a new line and stamps the prior as superseded.

Delivery receipts for branded notifications; providers report delivery independently of client actions.

The external client user master — every person on the customer side who logs into the portal. Two-namespace separation from internal Users keeps the auth surfaces and audit logs clean.