Tenant isolation

How trend ensures one workspace can't see another workspace's data.

Every workspace in trend is its own tenant. Data belongs to exactly one workspace, and cross-workspace access is impossible — enforced at multiple independent layers so a bug in one layer can’t break the guarantee.

Layer 1 — Every request is scoped

Every authenticated request carries a workspace context. Whether you signed in as a workspace member, arrived via a portal magic link, or hit us with an embed token, the server resolves your identity to exactly one workspace before running any database query. There is no request path in the product that reads across workspaces.

Layer 2 — Database policies

Every table that holds workspace data enforces workspace-scoping at the database layer itself. Even if application code tried to read across workspaces, the database would return zero rows. This is defense in depth — the app-layer scope check and the database-layer policy have to both agree that you belong to a workspace before any row comes back.

Layer 3 — Warehouse credentials

Warehouse credentials belong to a single workspace and are encrypted with a key held only in our deployment environment. See credential storage for the encryption details. There is no path — API, UI, or internal — by which one workspace can query another workspace’s warehouse.

Embed customers

When a workspace exposes dashboards to their own customers (iframe, web component, or portal), each embed customer is scoped further. An embed customer sees only dashboards their workspace explicitly granted them, and every underlying query is filtered by attributes bound to that customer’s signed token. One embed customer never sees another embed customer’s data — even inside the same workspace.

When you delete a workspace

Deleting a workspace cascades: dashboards, datasets, connections, encrypted credentials, embed customers, audit records, everything. There is no orphaned data left behind.