Roles & Permissions

Admin

HCSS Events Platform uses Role-Based Access Control (RBAC) to govern what each user can see and do. Every user is assigned exactly one role, and each role carries a set of permissions that control access to features, data, and actions throughout the platform.

🔒Requires permission: Roles.View

RBAC Principles

The platform follows these core RBAC principles:

1. Principle of Least Privilege -- users are granted only the minimum permissions needed to perform their job. This reduces the risk of accidental or unauthorized changes.
2. Role-Based, Not User-Based -- permissions are assigned to roles, not directly to individual users. To change what a user can do, you change their role.
3. Deny by Default -- if a permission is not explicitly granted by a user's role, access is denied. There are no implicit grants.
4. Separation of Duties -- critical operations (such as archiving events or managing system settings) are restricted to specific roles, ensuring no single role can perform all actions without oversight.
5. Auditability -- every permission-protected action is logged in the Audit Log, tied to the user and role that performed it.

The Six System Roles

The platform provides six built-in system roles. Each is designed for a specific function within the strike response workflow.

Admin

Admin

The Admin role has full, unrestricted access to every feature in the platform. Admins manage users, configure system settings, and have oversight of all events and data.

Typical responsibilities:

• Create and manage user accounts
• Assign roles to users
• Configure system settings (branding, email, security)
• Manage reference data (airports, hotels, specialties)
• Monitor audit logs and system health
• Access all events regardless of assignment

Key permissions: All permissions are granted.

caution

The Admin role should be assigned sparingly. Having too many Admin users increases the risk of accidental configuration changes. Most organizations need only two to three Admin accounts.

Leadership

Leadership

The Leadership role provides read-heavy access with visibility into all events, metrics, and reports. Leadership users monitor operations at a high level but do not typically make day-to-day data changes.

Typical responsibilities:

• View all events and their fill rates
• Access dashboards and KPI summaries
• Generate and export reports
• Review candidate pipelines and travel logistics

Key permissions:

• Events.View, Caregivers.View, Travel.View, Surveys.View
• Reports.View, Reports.Export
• Dashboard.View

Scheduler

Scheduler

The Scheduler role is focused on staffing and assignments. Schedulers work within assigned events to ensure all shift requirements are filled.

Typical responsibilities:

• Import caregivers into events via CSV
• Create and manage shift assignments
• Monitor fill rates and staffing gaps
• Communicate with candidates about assignments

Key permissions:

• Events.View, Events.Update
• Caregivers.View, Caregivers.Create, Caregivers.Update
• Assignments.View, Assignments.Create, Assignments.Update, Assignments.Delete
• FillRate.View
• Surveys.View, Surveys.Send

Travel Coordinator

Travel Coordinator

The Travel Coordinator role manages travel logistics -- flights, hotels, and ground transportation for caregivers deployed to strike events.

Typical responsibilities:

• Book flights and hotel accommodations
• Manage ground transportation schedules
• Track travel status and itinerary changes
• Coordinate arrival and departure logistics

Key permissions:

• Events.View
• Caregivers.View
• Travel.View, Travel.Create, Travel.Update, Travel.Delete
• Hotels.View, Airports.View

Supervisor

Supervisor

The Supervisor role oversees the candidate pipeline and survey operations. Supervisors manage caregiver records, track survey responses, and ensure candidates are ready for deployment.

Typical responsibilities:

• Review and update caregiver profiles
• Send and monitor surveys (availability, credentials, preferences)
• Track survey completion rates
• Manage pre-arrival checklists

Key permissions:

• Events.View
• Caregivers.View, Caregivers.Create, Caregivers.Update
• Surveys.View, Surveys.Create, Surveys.Send, Surveys.Update
• PreArrival.View, PreArrival.Update

OnsiteAdmin

OnsiteAdmin

The OnsiteAdmin role is used for on-site operations during an active strike. OnsiteAdmins handle check-in, badge distribution, orientation, and day-of logistics at the facility.

Typical responsibilities:

• Check in arriving caregivers
• Distribute badges and credentials
• Manage orientation scheduling
• Track daily headcount and attendance
• Record shift-level work data

Key permissions:

• Events.View
• Caregivers.View
• OnSite.View, OnSite.CheckIn, OnSite.Update
• WorkTracking.View, WorkTracking.Create, WorkTracking.Update
• Orientation.View, Orientation.Update

Permission Hierarchy

Permissions in the platform follow a hierarchical naming convention:

<Module>.<Action>

For example:

• Events.View -- view events
• Events.Create -- create new events
• Events.Update -- edit existing events
• Events.Delete -- delete events
• Events.Archive -- archive events (a special, irreversible action)

Common Action Levels

Action	Description
View	Read-only access to the module's data.
Create	Ability to create new records in the module.
Update	Ability to edit existing records.
Delete	Ability to remove or deactivate records.
Export	Ability to export data from the module (e.g., CSV, PDF).
Send	Ability to trigger outbound actions (e.g., sending surveys or emails).
Manage	Full control of the module, typically combining all other actions.

Permission Inheritance

Higher-level actions include lower-level ones in some cases:

• Manage implies View, Create, Update, Delete, and Export.
• Update implies View (you cannot edit what you cannot see).
• Create implies View.

This means that if a role has Events.Update, the user can also view events -- an explicit Events.View grant is not required but is included for clarity.

Role Comparison Matrix

The following matrix summarizes the key permissions for each role. A checkmark indicates the permission is granted.

Permission	Admin	Leadership	Scheduler	Travel Coordinator	Supervisor	OnsiteAdmin
Users.Manage	Yes	--	--	--	--	--
Roles.Manage	Yes	--	--	--	--	--
SystemSettings.Manage	Yes	--	--	--	--	--
AuditLogs.View	Yes	--	--	--	--	--
Events.View	Yes	Yes	Yes	Yes	Yes	Yes
Events.Create	Yes	--	--	--	--	--
Events.Update	Yes	--	Yes	--	--	--
Events.Archive	Yes	--	--	--	--	--
Caregivers.View	Yes	Yes	Yes	Yes	Yes	Yes
Caregivers.Create	Yes	--	Yes	--	Yes	--
Caregivers.Update	Yes	--	Yes	--	Yes	--
Assignments.Manage	Yes	--	Yes	--	--	--
Travel.Manage	Yes	--	--	Yes	--	--
Surveys.Manage	Yes	--	--	--	Yes	--
OnSite.Manage	Yes	--	--	--	--	Yes
WorkTracking.Manage	Yes	--	--	--	--	Yes
Reports.View	Yes	Yes	Yes	Yes	Yes	Yes
Reports.Export	Yes	Yes	--	--	--	--

Managing Roles

🔒Requires permission: Roles.Manage

Viewing Role Definitions

1. Navigate to Admin > Roles & Permissions.
2. The role list shows all six system roles with a summary of their permission count.
3. Click on any role name to see the full list of permissions assigned to that role.

Creating Custom Permission Sets

While the six system roles cover most use cases, Admins can create custom permission sets for specialized scenarios:

1. Navigate to Admin > Roles & Permissions.
2. Click Create Custom Role.
3. Enter a role name and description.
4. Select the permissions to include by checking the boxes in the permission tree.
5. Click Save.

info

Custom roles appear alongside the system roles when assigning roles to users. The system roles cannot be modified or deleted -- they serve as the baseline.

Editing a Custom Role

1. Open the custom role from the role list.
2. Click Edit Permissions.
3. Add or remove permissions using the permission tree checkboxes.
4. Click Save.

caution

Changes to a custom role take effect immediately for all users assigned to that role. If you remove a permission, every user with that role loses access on their next action. Review the user count shown on the role detail page before making changes.

Deleting a Custom Role

1. Open the custom role from the role list.
2. Click Delete Role.
3. If users are currently assigned to this role, you must first reassign them to a different role. The system will not allow deletion of a role that has active users.

Best Practices

1. Start with system roles -- the six built-in roles cover the vast majority of use cases. Only create custom roles when a system role is genuinely too broad or too narrow.
2. Limit Admin accounts -- keep the number of Admin users to the minimum necessary (typically 2-3). This reduces the risk of accidental configuration changes and provides clear accountability.
3. Review permissions quarterly -- schedule a regular review of role assignments. Remove access for users who have changed responsibilities.
4. Document custom roles -- if you create custom roles, document their purpose and the intended user group so that future administrators understand the design.
5. Use role names that describe function -- if creating custom roles, name them after the job function (e.g., "Regional Coordinator") rather than an individual's name.

Next Steps

• User Management -- create and manage user accounts.
• System Settings -- configure security policies that work alongside RBAC.
• Audit Logs -- review the audit trail for permission-protected actions.