Overview
Pilot provides the most robust RBAC (role-based access control) system on the LMS market. Every property and every action permission is configurable, giving you complete control over what users can see and do in the system.
These permission templates can be saved as Roles, which can then be assigned to users. A user can have multiple roles, and their permissions will be combined from all assigned roles.
To create roles and configure permissions, navigate to Settings → Roles and Permissions.
Understanding Permissions
Permissions in Pilot are organized into a three-level hierarchy:
Categories: High-level groupings of related functionality
Resources: Specific entities or features within each category
Permission Types: The specific access levels for each resource
Permission Categories
All permissions are organized into 8 categories:
Category | Description |
Cases | Permissions related to case management, line items, tasks, and production |
Clients | Permissions related to customers, doctors, offices, and communication |
Finance | Permissions related to invoices, payments, credits, and billing |
Integrations | Permissions related to external integrations and connections |
Operation | Permissions related to production, shipping, and operational workflows |
Reports | Permissions related to analytics and reporting features |
System | Permissions related to system configuration and settings |
User | Permissions related to user management and access control |
Each category contains multiple resources that can be individually configured.
Resource Permissions
Each resource has up to 5 main permission types:
Permission Type | Description |
View | Ability to see and read the resource |
Create | Ability to create new instances of the resource |
Update | Ability to modify existing instances of the resource |
Delete | Ability to remove instances of the resource |
Manage | Combined permission that grants Create, Update, and Delete access |
Note
Some resources have fewer permissions depending on their nature. For example, Case Warnings only have "View" permission because they are system-managed and cannot be manually created, updated, or deleted.
Additional Action Permissions
Beyond the main resource permissions, many resources have additional action permissions. These are boolean flags (true/false) that control access to specific actions within that resource.
Examples include:
Invoice cases
Ship cases
Assign tasks to others
Self-assign tasks
Export data
Property Permissions
Property permissions control access to individual fields within a resource. Each property can have one of three states:
State | Description |
None | User cannot read or update the property (field is hidden) |
Read | User can view the property but cannot modify it (read-only) |
Read and Update | User can both view and modify the property |
This granular control allows you to show or hide specific fields based on user roles. For example, you might allow technicians to see case due dates but not modify them, while production managers can both see and adjust due dates.
Special Permission Sections
Two areas in Pilot have permissions that work differently from the standard resource-based model:
My Work page
Communications Hub
My Work (Cases Category)
The My Work page has special permissions that, when granted, imply access to multiple related actions:
View production and exception tasks
Manage tasks (update task status)
Assign tasks (if additional action permissions allow)
View case details
Leave comments on cases
Upload files and scans
Mark tasks as complete
See My Work for more details on this page.
Communications Hub (Customers Category)
The Communications Hub has special permissions that imply access to communication-related actions:
View cases
View all case communication (messages and comments)
Log calls
Add exception tasks for cases
See Communications Hub for more details on this page.
Creating and Managing Roles
Creating a Role
Navigate to Settings → Roles and Permissions, "Roles" tab
Click Create Role
Enter a Name and Description for the role
Configure permissions for each category and resource as needed
Save the role
Assigning Roles to Users
Users can be assigned multiple roles, and their effective permissions will be the combination of all assigned roles. Here's how combined permissions work:
If any role grants a permission, the user has that permission
More permissive settings override more restrictive ones
For property permissions, "Read and Update" overrides "Read", which overrides "None"
Example:
If a user has two roles:
Role A: Cases - View only
Role B: Cases - Create and Update
The user will have View, Create, and Update permissions for cases (the combination of both roles).
Required Role Assignment
If a user has no roles assigned, they will not be able to log in to the system. Every user must have at least one role.
Best Practices
Role Design
Create role templates for common positions: Technician, Production Manager, Billing Administrator, Sales Representative, etc.
Use descriptive names and descriptions: Make it clear what each role is for and who should have it
Start restrictive, expand as needed: It's easier to grant additional permissions than to remove them
Review regularly: Periodically audit roles to ensure they still match your organizational needs
User Assignment
Assign multiple roles when needed: Rather than creating overly permissive single roles, combine smaller focused roles
Review user access: Regularly review which users have which roles and remove unnecessary access
Permission Granularity
Use property permissions for sensitive data: Hide financial information from production staff, hide production details from billing staff
Test new roles: Create test users with new roles to verify they have appropriate access before assigning to real users
Troubleshooting
User Cannot Log In
Problem: User receives an error when trying to log in
Solution: Verify the user has at least one role assigned. Users with no roles cannot access the system.
User Cannot See Expected Features
Problem: User is missing menus, pages, or buttons they should have access to
Solution:
Check if the user's roles grant the necessary "View" permission for that resource
Verify property permissions are set to at least "Read" for fields that should be visible
Confirm any required additional action permissions are enabled
Cannot Perform Specific Action
Problem: User can view a resource but cannot perform a specific action (e.g., invoice a case)
Solution: Check that the user has both:
The main resource permission (e.g., "Update" for cases)
The specific additional action permission (e.g., "Invoice cases")
If you're still experiencing issues, please contact [email protected]