Professional Services
May 27, 2026
How workspace-scoped RLS hardened a multi-tenant portal
Workspace-scoped write controls and preference-aware notification dispatch were added to the portal codebase.
| Before | After |
|---|---|
| Write paths needed explicit tenant boundaries | Workspace-scoped write policies across core records |
| Notification events needed recipient preference checks | Preference-aware dispatch functions for documented events |
| Infrastructure assumptions needed a testable handoff | Auth, storage, backup, and security checks recorded with limitations |
Put the tenant boundary below the application
A shared portal can filter records in every page and server action, but that leaves isolation dependent on every future code path remembering the rule. This build moved the critical boundary into PostgreSQL row-level security, where policies can restrict which rows a role may read or modify.
The migration applied workspace-aware write policies to projects, tasks, notes, files, folders, channels, channel membership, messages, and clips. Some records inherited workspace access through a parent record, while shared team rooms used a separate role check. That kept each policy close to the relationship it protected.
Treat notifications as preference-aware dispatch
The notification module did more than call an email function. It resolved eligible recipients, excluded the person who caused the event, loaded each recipient's saved preference, and then dispatched the matching message.
Documented dispatchers covered chat messages, task assignment and completion, task updates, approval requests, program changes, shared files, and room membership. Errors were logged without blocking the user action that triggered them.
That code is evidence of implemented routing logic. It is not evidence that a mail provider was configured or that every message reached an inbox.
Make the handoff state what remains unfinished
The infrastructure guide recorded authentication checks, tenant-scoped row-level security behavior, private storage access, a database backup job, and restore procedures. It also named two material limits: outbound email was not yet enabled, and backup copies remained on the same host.
Those limits matter. A configured dispatcher is not an operational notification system until a live message succeeds. A local backup is not disaster recovery until a copy survives loss of the application host.
The reusable decision
For multi-tenant portals, place access control in the database, keep event dispatch aware of user preferences, and write handoff documentation that distinguishes implemented code from verified operations. That produces a system another engineer can inspect without turning unfinished work into a success claim.
FAQ
Frequently asked questions
01Why enforce tenant boundaries in Postgres?
Database policies protect shared records even when an application action forgets a workspace check. The migration added scoped insert, update, and delete rules to the main write paths.
02What did the notification layer implement?
The code resolved recipients, read their saved preferences, and dispatched documented message, task, approval, program-change, file, and room-membership events. Source code proves the implementation, not successful delivery from a live mail service.
03What did the infrastructure handoff verify?
It recorded working authentication, row-level security behavior, private storage access, and a local backup job. It also recorded that email delivery and off-host backup copies still needed separate completion and verification.
