Roles and Permissions

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 Admin → Roles and Permissions.

Understanding Permissions

Permission Structure

Permissions in Pilot are organized into a three-level hierarchy:

1. Categories: High-level groupings of related functionality
2. Resources: Specific entities or features within each category
3. 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 (Cases Category)

The My Work page has special permissions that, when granted, imply access to multiple related actions:

Implied capabilities when "View" permission is granted:

• 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 (Clients Category)

The Communications Hub has special permissions that imply access to communication-related actions:

Implied capabilities when "View" permission is granted:

• 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

1. Navigate to Admin → Roles and Permissions
2. Click Create Role
3. Enter a Name and Description for the role
4. Configure permissions for each category and resource as needed
5. Save the role

Role Properties

Each role has two main properties:

• Name: A descriptive name for the role (e.g., "Production Manager", "Billing Administrator", "Technician")
• Description: A detailed explanation of what this role is for and what access it grants

Assigning Roles to Users

Users can be assigned multiple roles, and their effective permissions will be the combination of all assigned roles.

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.

Permission Configuration Flexibility

The majority of places in Pilot can be configured very granularly to meet your specific needs:

• Custom workflows: Configure permissions to match your lab's unique processes
• Department-specific access: Create roles for different departments with only the permissions they need
• Training and onboarding: Start new users with limited permissions and expand access as they gain experience
• Compliance and security: Restrict access to sensitive financial or patient data to authorized users only
• Multi-location labs: Configure different permissions for different office locations or teams

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
• Document role assignments: Keep track of why users have specific roles for compliance and auditing
• 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
• Leverage additional action permissions: Control specific actions without granting full resource access
• Test new roles: Create test users with new roles to verify they have appropriate access before assigning to real users

Examples

Example 1: Production Technician Role

Permissions:

• Cases: View, Update (limited properties)
• My Work: View (with self-assign tasks)
• Line Items: View only
• Production Tasks: View, Update
• Scans & Attachments: View, Create

Use case: Technicians can see their assigned work, update task status, upload files, but cannot modify financial information or delete cases.

Example 2: Billing Administrator Role

Permissions:

• Cases: View only
• Finance: Manage (full access)
• Invoices: Manage (full access)
• Payments: Manage (full access)
• Clients: View only
• Reports: View (financial reports)

Use case: Billing staff can manage all financial operations but cannot modify production schedules or case details.

Example 3: Production Manager Role

Permissions:

• Cases: Manage (full access)
• My Work: View all workstations, assign tasks to others
• Production Tasks: Manage (full access)
• Exception Tasks: Manage (full access)
• Clients: View only
• Reports: View (production reports)

Use case: Production managers can oversee all production activities, assign work, manage tasks, and view production metrics without access to financial operations.

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:

1. Check if the user's roles grant the necessary "View" permission for that resource
2. Verify property permissions are set to at least "Read" for fields that should be visible
3. Confirm any required additional action permissions are enabled

Too Many Permissions After Role Combination

Problem: User has more permissions than intended when multiple roles are combined Solution: Review all assigned roles and remove roles that grant unwanted permissions. Consider creating more specific roles with narrower permissions.

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:

1. The main resource permission (e.g., "Update" for cases)
2. The specific additional action permission (e.g., "Invoice cases")

Related Documentation

• Users: Learn how to create and manage user accounts
• My Work: Understand the production task management interface
• Communications Hub: Learn about the centralized communication interface