Permissions Matrix

This matrix defines the actions available to each user role across all PlaneConnection modules. Permissions are enforced at both the UI and API layers — the UI hides inaccessible elements, and the API rejects unauthorized requests regardless of how they are made.

​

Legend

​

Special Permissions

Certain actions require explicit authorization beyond the standard CRUD model.

---

​

Distinguishing Admin-Level Roles

PlaneConnection has four roles with broad administrative capabilities. Understanding the differences is important for proper role assignment.

---

​

Permission Sets

Permission sets are composable permission bundles that layer additional capabilities on top of a user’s base role. They provide flexibility for organizations whose management structures do not map cleanly to a single role.

​

How Permission Sets Work

A permission set defines a map of resources to actions, just like a role does. When assigned to a user, the set’s permissions are merged with the user’s base role permissions. If any source (base role or any assigned set) grants an action on a resource, the user has that permission.

​

Creating and Managing Permission Sets

Permission sets are managed under Settings > Permission Sets by Admin or Account Owner users:

1. Create a permission set with a name, description, and permissions JSON mapping resources to allowed actions.
2. Assign the set to one or more users. A user can have multiple sets assigned simultaneously.
3. Revoke a set from a user when access is no longer needed. Revocations are soft-deleted, preserving the audit trail.
4. Delete a custom set when it is no longer needed. All user assignments are automatically removed.

​

System vs Custom Sets

​

Regulatory Constraint

​

Example Use Cases

All permission set operations are logged to the workspace audit log.

---

​

Ops-RBAC: Financial Access and Aircraft Scoping

The Operations module adds two additional permission layers beyond the standard RBAC matrix: financial access gating and aircraft scoping.

​

Financial Access

The accounting resource is gated by financial access. Users without financial access cannot read financial data (invoices, expenses, payment records, revenue), even if their base role includes accounting: [read]. Financial access is granted in two ways:

​

Aircraft Scoping (Owner Role)

The owner role is scoped to specific aircraft. When an aircraft owner accesses flights, aircraft records, maintenance items, or accounting data, the platform automatically filters results to only the aircraft they own. Aircraft ownership is managed under Settings > Members by assigning aircraft IDs to the aircraft owner’s profile.

---

​

Portal-Scoped Roles

Three roles are scoped exclusively to customer-facing portals and cannot access any operator-side module: Portal roles access the platform at /{workspace}/portal through a dedicated login. They see only their own data and cannot navigate to operator-side routes. Attempting to access an operator route results in a redirect to the sign-in page.

---

​

Notes

• Own access means the user can only access records where they are the author, assignee, or a member of the assigned crew.
• The platform_admin role (PlaneConnection staff only) has unrestricted access across all workspaces and is not subject to workspace-level permission checks. It is omitted from the matrices above for clarity.
• The system_administrator role has full access to all resources plus platform workspace management. It is also omitted from the per-module matrices for clarity.
• The Accountable Executive role has read and approve access across most SMS and ops resources but cannot create or manage records directly. This reflects the oversight nature of the role per 14 CFR 5.23.

​

Related