Role-Based Access Control (RBAC) Changes

Background

Initially, the application launched with three roles: System Admin, Admin, and Student/Resident. However, every user in Administration was categorized as an Admin, which opens the door for unintended access issues:

• Admins could switch between facilities, gaining access to data they were not authorized to see.
• Admins could unknowingly modify data in facilities they were not responsible for.

To address this and support other needs in the platform, we implemented Issue #715, introducing two new roles: Department Admin and Facility Admin. These roles ensure a clearer separation of responsibilities:

• Department Admins oversee multiple facilities.
• Facility Admins manage team members and residents within a single facility.

Access Differences

Initially there may not be much of a difference from what a Department Admin can do versus a Facility Admin. But for example:

• Department Admins can view dashboards across all facilities and drill down into specific ones.
• Facility Admins can only access dashboards for their assigned facility.

Over time, we will refine role-based permissions. Below is the current breakdown of permissions.

Role Permissions

Role	Switch Facilities	Create Department Admins	Create Facility Admins	Create Student Accounts
System Admin	✅	✅	✅	✅
Department Admin	✅	❌	✅	✅
Facility Admin	❌	❌	❌	✅

Open to Change

Some users may find it cumbersome that Department Admins are required to create Facility Admins and that System Admins handle department-level access. Over time, we may introduce additional roles (e.g., Coordinator or Instructor), at which point an Admin role may be used to manage access control without burdening other users.

It’s important to note:

• It's easier to grant more access over time than to revoke existing privileges.
• A stricter permissions model prevents unintended access issues from the start.