Role-Based Access Control: Who Sees What and Why

A 50-person production company has crew members, department leads, payroll administrators, and owners. They all use the same platform, but they should not all see the same data. A stagehand does not need access to the company's payroll summary. A department lead should see their own crew's schedules but not another department's financials. The owner needs visibility into everything. Role-based access control makes this possible without building a separate app for each audience.

Default Roles and What They Unlock

JamCrew ships with four default roles that cover the most common organizational structures in production companies. The Owner role has unrestricted access to every feature, including billing, workspace settings, and the ability to delete the workspace entirely. Admins can manage crew, gigs, clients, and payroll, but cannot modify billing or workspace-level settings. Managers see their assigned crew and gigs, can approve timesheets for their department, and can create new gigs within their scope. Crew members see only their own gigs, schedule, pay history, and messages.

Each role is a bundle of permissions. The system checks permissions at two levels: navigation visibility and data access. A crew member's sidebar does not show the payroll section at all. Even if they somehow constructed a direct URL to the payroll page, the server-side query would return nothing because their role lacks the required permission.

Custom Roles for Specific Workflows

Default roles work for most companies, but production is messy. Some companies have a dedicated payroll person who should see financials but not edit the schedule. Others have freelance coordinators who need to manage crew profiles but should not see pay rates. Custom roles let workspace admins compose exactly the permission set they need.

The custom role builder presents permissions in plain language, not technical jargon. Instead of "read:payroll" and "write:gigs", the interface uses descriptions like "View pay runs and timesheet summaries" and "Create and edit gig postings." Each permission includes a brief explanation of what it grants, so the admin creating the role understands the implications before saving.

Custom roles inherit nothing by default. This follows the principle of least privilege: start with zero access and add only what is needed. It is safer to have someone request additional access than to discover they had access to sensitive data they never should have seen.

Data Isolation at the Query Level

Permissions in JamCrew are not just a frontend concern. Every query and mutation in the backend validates the requesting user's role and permissions before returning data or executing a change. This is enforced through TypeScript wrapper functions in Convex that every tenant-scoped operation must use.

When a Manager queries the crew list, the wrapper automatically scopes the results to crew members in their department. When a Crew member queries their pay history, the wrapper returns only their own records. These constraints are structural, not optional. A frontend bug that accidentally requests all crew records will still receive only the records the user is authorized to see.

This server-side enforcement is critical in a multi-tenant system. Tenant data isolation and role-based access control work together. A user must belong to the correct tenant and have the correct role to access any given piece of data. Both checks happen on every request.

Audit Logging and Compliance

Every permission-sensitive action in JamCrew generates an audit log entry. When an admin changes a crew member's pay rate, the log records who made the change, what the previous value was, what the new value is, and when it happened. When a custom role is modified, the log captures the before and after permission sets.

Audit logs serve two purposes. First, they enable accountability. If a pay rate was changed incorrectly, the admin can trace exactly when it happened and who made the change. Second, they support compliance requirements. Production companies that work with venues or corporate clients often need to demonstrate that they have access controls and change tracking in place.

The audit log is append-only. No user, including the Owner, can delete or modify log entries. This ensures the historical record remains trustworthy regardless of future role changes or personnel turnover. The logs are retained for the lifetime of the workspace and can be exported for external review.