What it means
B2B Silos are the trust boundary inside the partner platform. Agencies, users, projects, clients, deliveries, and notifications carry tenant context so access can be checked before rows are returned.
The promise is plain: one agency should not see another agency's clients, projects, artifacts, or operational data. The platform is designed around that separation instead of treating it as a UI-only filter.
How it works
- Tenant tables carry an agency identifier as part of the data model.
- Postgres Row-Level Security checks agency membership before returning rows.
- Role helpers separate owner, admin, editor, and viewer permissions.
- Service-role access is reserved for controlled server-side operations.
What it protects
- Partner agencies from cross-tenant data exposure.
- End-client project details from appearing in the wrong workspace.
- Internal delivery data from becoming visible through UI mistakes.
- White-label trust when multiple agencies use the same operational platform.
Best fit
- You need a partner portal where agencies cannot see each other.
- You manage client projects, deliveries, change orders, or CMS content across tenants.
- You want the access model enforced by the database, not only by frontend screens.
Control signals
- Tenant records are scoped by agency membership.
- RLS is enabled on core multi-tenant tables.
- Role checks gate modification rights for sensitive rows.
- CMS and media tables follow the same agency isolation pattern.
Questions agencies ask
What does RLS mean?
RLS means Row-Level Security. The database checks access rules per row, so a user only receives records they are allowed to see.
Is this different from hiding data in the UI?
Yes. UI hiding is presentation. RLS is a database-level control that helps prevent accidental cross-tenant exposure.
Does every project get a separate app?
Not necessarily. The platform can support many agencies in one system because tenant boundaries are built into the data model.