Multi-tenant security
How SERA Keeps Organization Data Isolated
A service-management platform can serve many companies while treating each company as a separate security boundary. That separation cannot depend on the interface hiding another organization's records. SERA resolves the organization from an authenticated user's verified active membership before tenant-sensitive operations are performed; it is not a fact the browser gets to declare as trusted.
Identity and membership establish the tenant context
The canonical path begins with a bearer token verified server-side through Supabase auth. The Proxy resolves active organization membership and derives the organization from that verified context before applying service, module, role or resource rules.
Privileged database access needs explicit server-side scoping
Several operational tables use a deliberate Proxy/service-role pattern: RLS is enabled, direct anon/authenticated access is revoked, and the server-side service-role client performs privileged queries. Service-role credentials are not available to the frontend.
RLS does not automatically tenant-filter a service-role query. The Proxy must authorize the caller and explicitly scope privileged queries to the resolved organization. That backend decision is the boundary.
Organization isolation follows the operational record
Service Management records—including customers, customer equipment, work orders, estimates, approvals, schedule allocations and attachments—are organization-scoped. The work order is an operational aggregate, and related ownership checks prevent an unrelated record from being used as context.
Secrets and sensitive logs stay out of the client
Service-role and AI credentials remain server-side. Current voice-draft logging is designed for safe metadata rather than raw audio, bearer tokens, full transcripts, secrets or sensitive work-order details; provider/model error messages are not logged when they could expose request context.
Isolation is an ongoing engineering responsibility
The pattern depends on every sensitive flow keeping its authorization, organization scoping and related-resource validation intact. It is not a claim of universal compliance certification or an excuse to trust frontend state.
Separate companies need separate operational histories
The purpose is practical as well as technical: one company should not be able to access another company's customers, machines, work orders or internal service history through a manipulated URL, request or application state.
Next pages to check
Keep operational access tied to the right organization
SERA Service Management is built around server-verified membership, scoped records and deliberate authorization boundaries.