Why Multi-Tenancy Matters in Aviation
PlaneConnection serves multiple aviation organizations from a single platform. Each organization — whether a Part 135 charter operator, a corporate flight department, or a fractional ownership program — needs absolute confidence that its safety data, operational records, and personnel information are invisible to every other organization on the platform. This is not just a technical preference. Aviation safety data is sensitive. Safety reports may describe incidents that have regulatory, legal, or insurance implications. Operational data includes flight schedules, passenger manifests, and financial information. Personnel records contain training histories, medical status, and certification details. Any cross-contamination of this data between organizations would be unacceptable.How PlaneConnection Isolates Data
Workspace Model
Every organization in PlaneConnection operates within its own workspace. A workspace is identified by a unique slug — a short, URL-safe identifier likeskyline or global-jets — that appears in every URL within the application. When you navigate to planeconnection.com/skyline/safety/reports, you are viewing safety reports that belong exclusively to the Skyline organization.
This workspace slug is not cosmetic. It is the entry point for a chain of data isolation that extends from the URL through the application layer and into the database.
Database-Level Isolation
At the database level, every record that belongs to an organization includes atenant_id column. Every query that reads or writes data filters on this tenant ID. This means that a database query executed in the context of Organization A will never return records belonging to Organization B, regardless of the query’s other parameters.
This filtering is enforced at the application layer, not the database layer, which means it applies consistently across all modules — safety reports, risk assessments, investigations, CPAs, crew records, aircraft, trips, documents, and every other data type in the system.
Tenant ID filtering is applied in the server-side data access layer. Client-side code never constructs queries directly. This architectural boundary ensures that data isolation cannot be bypassed by client-side manipulation.
Authentication and Authorization
Users are authenticated at the platform level and associated with a specific tenant. When a user logs in, their session includes their tenant ID, which determines which workspace they can access and what data they can see. Authorization operates within the tenant boundary. A user with a “safety_manager” role in Organization A has safety management permissions only for Organization A’s data. They cannot see, access, or modify data belonging to any other organization.URL-Level Enforcement
Every workspace-scoped route in PlaneConnection includes the workspace slug as a URL parameter. The application’s routing layer validates this parameter on every request, confirming that the authenticated user has access to the requested workspace. Requests for workspaces the user does not belong to are rejected before any data is accessed.Workspace Configuration
Each workspace has its own configuration, independent of every other workspace:| Setting | Scope |
|---|---|
| Safety policy and objectives | Per workspace |
| Risk assessment criteria | Per workspace |
| User roles and permissions | Per workspace |
| Enabled modules (Safety, Operations) | Per workspace |
| Subscription tier and limits | Per workspace |
| Document storage | Per workspace |
| Notification preferences | Per workspace |
| Integration settings | Per workspace |
Platform Administration
PlaneConnection platform administrators can manage multiple workspaces for operational support purposes. This administrative access is strictly controlled, audited, and limited to platform-level functions such as provisioning new workspaces, managing subscription tiers, and providing technical support.Administrative access to a workspace for support purposes is logged and visible. PlaneConnection supports impersonation workflows where a platform administrator can view a workspace in the context of a specific user, with clear visual indicators that impersonation is active. This provides support capability while maintaining transparency.