Feature 01 / 04
Foundation
Multi-tenant by design, not by retrofit
Helpdash was built tenant-first. Every query carries a workspace boundary at the data layer; every workspace owns its rows, its storage prefix, its roles, its audit log. There is no path — authenticated or not — where a tenant scope is optional. For engineering and security teams: this is the architecture you'd ask for in a procurement review.
Outcomes
The isolation guarantees that survive an audit
Multi-tenant isn't a feature flag we ship. It's the data model: row-level scope at every read and write, team-aware RBAC, scoped storage, signed audit log. Procurement, SOC 2, ISO 27001 — the answers are the same on every form.
Feature 02 / 04
Workspace-scoped RBAC
roles live inside a tenant, permissions never leak across the boundary
Feature 03 / 04
Per-workspace storage prefix with signed, short-lived download URLs — no shared bucket, no cross-tenant path traversal
Feature 04 / 04
Tamper-evident audit log retained beyond workspace deletion to meet regulatory retention windows
Inside the model
How Helpdash makes multi-tenancy boring
Feature 01 / 03
Global query scope
A global scope on every model auto-filters by tenant key. Forgetting the boundary at call sites is structurally impossible; the framework wires it in at the data layer.
Feature 02 / 03
Team-level RBAC
Roles and permissions are tenant-aware — an agent's role in workspace A is invisible in workspace B. No accidental privilege carry-over across desks.
Feature 03 / 03
Per-tenant storage
Filesystem prefixes (tenants/{id}/) bound every upload to its workspace. Download URLs are signed, short-lived, and tenant-checked at issue time.
FAQ
Frequently asked questions
What's the data model?
A single shared schema with a tenant key on every business record. Models use a BelongsToTenant trait that installs a global query scope; reads and writes inherit the workspace boundary automatically. Cross-tenant access requires an explicit, audited override at the application layer.
How is the tenant resolved on each request?
Authenticated routes ignore X-Tenant-Slug and host headers — the workspace claim inside the signed JWT is authoritative, full stop. Unauthenticated routes (login, public docs) resolve via header → subdomain → query string, in that priority, with a reserved-name list (e.g. www, api, admin) preventing collisions.
What does an auditor actually see?
A signed, append-only audit log per workspace, retained past tenant deletion, exportable to your SIEM. Plus the ORM scope: a one-line proof that every query is tenant-bound, which is usually enough for SOC 2 CC6.1 and ISO 27001 A.9.4.1.
See the isolation model in your own workspace
Spin up two workspaces under one login and watch them never see each other — at the API, the UI, or the storage layer. Free plan, no credit card.