Tenant scoping and document isolation
MobilityManager is multi-tenant: several companies share one platform without seeing each other's data. This article explains how documents are isolated to your company and what enforces that boundary.
What "tenant" means here
A tenant is a company (client) on the platform. Each tenant has its own database, and document records — their metadata and version history — live in that tenant's database. There is no shared pool of documents across companies; a document belongs to exactly one tenant.
Every document operation requires a tenant context
Before any upload, download, metadata listing, or deletion runs, the platform validates that your session has an active tenant context and that the tenant's database is reachable. If either check fails, the operation stops immediately with "Tenant context is required for document operations." No file is read or written without a resolved tenant.
Note: This check is mandatory and applies to all document actions. It is enforced on the server, so it cannot be bypassed from the interface.
Two layers of protection
| Layer | What it enforces |
|---|---|
| Permissions | documents:view to list and download, documents:manage to upload and delete. Checked server-side on every request. |
| Tenant scope | Requests run against your tenant's database only. Queries also match the parent record (its type and ID), so a document is reachable only through the record it belongs to. |
Together these mean that having permission is not enough to reach another company's files — the tenant context and the database boundary keep operations inside your own company.
How storage backends stay opaque
File content is stored under server-generated random names, not original file names or any customer-identifying text. Even where multiple tenants share the same storage backend (for example one bucket), stored objects are opaque identifiers, and the mapping from a document to its stored file exists only inside the owning tenant's database. Combined with encryption at rest, the storage layer holds no readable, attributable content.
What is shared and what is not
| Shared across the platform | Isolated per tenant |
|---|---|
| Document categories (the system-wide label list) | The documents themselves and their versions |
| The active storage provider configuration | Which record each document is attached to |
| The encryption setting and key | Uploader identity and audit details |
In other words, administrators define one set of categories and one storage configuration for everyone, but the files and their metadata never cross the tenant boundary.
Tip: If a user suddenly cannot see documents they could see before, check whether their active company changed. Documents are only visible while the matching tenant context is active in the session.
Related
- How documents work across the platform
- Encryption at rest and the encryption key
- Where documents are stored: Local, Azure Blob, and S3 providers
- Document retention and permanent deletion
