HCM Permission System Guide

Overview

The HCM permission system controls what users can see and do in the application. This guide explains how permissions work, how they're organized, and how they're assigned to users.

Table of Contents

1. Quick Summary
2. Understanding Permission Types
3. Groups and Roles Explained
4. How Users Get Permissions
5. Priority System
6. System Administrators
7. Common Examples
8. FAQ

Quick Summary

What you need to know:

• Permissions control what actions users can perform (like editing patient records or viewing reports)
• Roles are job titles (like "Admin", "Coordination Manager", "Clinical Director")
• Groups organize related roles (like Admin group, Clinical group, Coordination group)
• There are two types of permissions: Grant (allows access) and Restrictive (denies access)
• Users receive permissions through their assigned roles or through custom permissions

Understanding Permission Types

Grant Permissions (Allow Access)

What they are:

Grant permissions are "allow" rules that give users the ability to perform specific actions.

How they work:

• These are like adding someone to an approved list
• If your role is listed in a Grant permission, you can perform that action
• Most permissions in HCM are Grant permissions

Example:

• Permission Name: CanEditOldCertPeriods
• What it does: Allows users to edit certification periods that are older than normal
• Who has it: Users with the "Admin" role or "Clinical Director" role
• Result: Only these roles can edit old certification periods; everyone else cannot

Think of it like: A VIP list at an event - if your name is on the list, you get in.

Restrictive Permissions (Deny Access)

What they are:

Restrictive permissions are "deny" rules that prevent users from performing specific actions, even if they might normally have access.

How they work:

• These are like a "do not allow" list
• If your role is listed in a Restrictive permission, you CANNOT perform that action
• These override normal access
• Used when you need to explicitly block certain roles from doing something

Example:

• Permission Name: CannotDeletePatientRecords
• What it does: Prevents specific roles from deleting patient records
• Who it affects: Users with "Clinical Assistant" or "Intake Coordinator" roles
• Result: These roles cannot delete patient records, even if they can view and edit them

Think of it like: A "No Entry" sign - if your role has this restriction, you cannot perform this action, no matter what.

Grant vs. Restrictive: The Key Difference

Important Rule: Restrictive permissions take priority. If you have a Restrictive permission, it blocks access even if a Grant permission says you should have access.

Groups and Roles Explained

What are Groups?

Groups organize roles by department or function. Think of them as departments in your organization.

HCM Groups include:

• Admin - Administrative roles
• Clinical - Clinical and nursing roles
• Coordination - Care coordination roles
• HR - Human resources roles
• Billing - Billing and finance roles
• Intake - Patient intake roles
• Marketing - Marketing and outreach roles
• Payroll - Payroll processing roles
• And more...

Why groups matter:

Groups help organize permissions logically. When setting up permissions, you can target an entire group or specific roles within a group.

What are Roles?

Roles are specific job positions within a group. Each role represents a level of responsibility and access.

Example - Clinical Group Roles:

• Clinical Director (highest authority in Clinical group)
• Nurse Supervisor
• RN (Registered Nurse)
• LPN (Licensed Practical Nurse)
• Clinical Assistant (lowest authority in Clinical group)

Example - Admin Group Roles:

• System Administrator (highest authority)
• Admin Manager
• Admin
• Admin Assistant (lowest authority)

Why roles matter:

Your role determines what permissions you have. More senior roles typically have more permissions than junior roles.

How Users Get Permissions

Users can receive permissions in three different ways:

1. Through Role Assignment (Most Common)

How it works:

• When you're hired or assigned a position, an administrator assigns you one or more roles
• Roles are assigned per company (if your organization has multiple companies)
• You automatically inherit all permissions associated with that role

Example:

• Sarah is assigned the "Coordination Manager" role
• The "Coordination Manager" role has the CanApproveVisitSchedules permission
• Sarah automatically receives permission to approve visit schedules

Where this happens: Administrators assign roles in the User Management section of HCM.

2. Through Custom Permissions (Special Cases)

How it works:

• Sometimes a specific user needs a permission that their role doesn't normally have
• Administrators can assign individual permissions directly to a user
• These are called "custom permissions" or "permission claims"
• Custom permissions are separate from role permissions

Example:

• John is a "Clinical Assistant" (normally cannot approve authorizations)
• The manager gives John temporary permission to approve authorizations while the supervisor is on vacation
• John receives a custom CanApproveAuthorizations permission just for him
• When John's temporary assignment ends, the administrator removes this custom permission

When to use custom permissions:

• Temporary elevated access
• Special project assignments
• One-off exceptions to normal role permissions

3. Through System Administrator Role (Full Access)

How it works:

• Users with the "System Administrator" role have special treatment
• They automatically have all Grant permissions without needing them explicitly assigned
• They bypass all Restrictive permissions (with some exceptions for security)

Example:

• Linda is a System Administrator
• A new permission CanExportFinancialReports is created
• Linda can immediately export financial reports without any additional setup
• Other users need this permission specifically granted to their roles

Important: System Administrators have nearly unlimited access and should be assigned carefully.

Priority System

What is Priority?

Every role has a priority number that indicates its level of authority within its group.

Key Rule: Lower number = Higher authority

Example - Coordination Group:

Priority 1: Coordination Director (highest authority)
Priority 2: Coordination Manager
Priority 3: Care Coordinator
Priority 4: Coordination Assistant (lowest authority)

How Priority Affects Permissions

Priority determines which roles within a group can access certain features:

For Grant Permissions:

• When a permission specifies a role, users with that role OR a higher-priority role in the same group can access it
• Higher-priority roles inherit permissions from lower-priority roles in their group

Example:

• Permission: CanEditCoordinationReports
• Granted to: "Care Coordinator" (Priority 3)
• Result:
  • Care Coordinator (Priority 3) ✓ Can edit reports
  • Coordination Manager (Priority 2) ✓ Can edit reports (higher authority)
  • Coordination Director (Priority 1) ✓ Can edit reports (highest authority)
  • Coordination Assistant (Priority 4) ✗ Cannot edit reports (lower authority)

For Restrictive Permissions:

• When a restriction specifies a role, users with that role OR a lower-priority role in the same group are restricted
• Restrictions flow down to lower-priority roles

Example:

• Permission: CannotDeleteFinancialRecords
• Applied to: "Billing Manager" (Priority 2)
• Result:
  • Billing Director (Priority 1) ✓ Can delete (higher authority, exempt)
  • Billing Manager (Priority 2) ✗ Cannot delete (restriction applies)
  • Billing Clerk (Priority 3) ✗ Cannot delete (lower authority, inherits restriction)

Why Priority Matters

Benefit 1: Automatic Hierarchy
Senior roles automatically get permissions that junior roles have, without manually assigning each permission.

Benefit 2: Security
Restrictions on senior roles automatically apply to junior roles, ensuring consistent security policies.

Benefit 3: Easy Management
When you grant a permission to a role, all higher roles get it automatically - no need to update multiple roles.

System Administrators

Special Rules for System Administrators

System Administrators have unique permission behavior:

What they can do:

• ✓ Automatically have ALL Grant permissions
• ✓ Bypass most Restrictive permissions
• ✓ Access all modules and features
• ✓ Manage other users' permissions

What they follow:

• ✗ Still subject to role hierarchy checks in some cases
• ✗ Some security-critical actions may still require explicit permission
• ✗ Audit logs still track all their actions

When to use:

• IT administrators who manage the system
• Executive leadership who need full system access
• Implementation and support teams

Security note: Use System Administrator role sparingly. Most users should have specific roles with appropriate permissions.

Common Examples

Example 1: Clinical Record Access

Scenario: Control who can edit patient clinical records

Setup:

1. Create Grant permission: CanEditClinicalRecords
2. Assign to roles:
   • Clinical Director ✓
   • Nurse Supervisor ✓
   • RN (Registered Nurse) ✓
3. Result: Only these three roles (and System Administrators) can edit clinical records

Who can edit:

• Clinical Director (explicitly granted)
• Nurse Supervisor (explicitly granted)
• RN (explicitly granted)
• System Administrator (automatic)

Who cannot edit:

• LPN (not granted)
• Clinical Assistant (not granted)
• All other roles outside Clinical group

Example 2: Preventing Deletion of Old Records

Scenario: Prevent junior staff from deleting records older than 90 days

Setup:

1. Create Restrictive permission: CannotDeleteOldRecords
2. Apply to roles:
   • Clinical Assistant ✗
   • LPN ✗
   • Intake Coordinator ✗
3. Result: These roles cannot delete old records, even if they can delete recent records

Who is restricted:

• Clinical Assistant (explicitly restricted)
• LPN (explicitly restricted)
• Intake Coordinator (explicitly restricted)

Who can still delete:

• Clinical Director (not restricted)
• Nurse Supervisor (not restricted)
• System Administrator (bypasses restriction)

Example 3: Temporary Project Access

Scenario: Give a coordinator temporary permission to approve authorizations

Setup:

1. User: Maria (Care Coordinator)
2. Normal permissions: Can view and edit authorizations, but cannot approve them
3. Temporary need: Supervisor on vacation for 2 weeks
4. Solution: Add custom permission CanApproveAuthorizations to Maria's user account
5. After 2 weeks: Remove custom permission from Maria

Result:

• Maria can approve authorizations for 2 weeks
• Her role (Care Coordinator) doesn't change
• Other Care Coordinators don't get this permission
• After removal, Maria returns to normal permissions

Example 4: Department-Wide Access

Scenario: Allow all Coordination staff to view financial reports

Setup:

1. Create Grant permission: CanViewFinancialReports
2. Assign to roles in Coordination group:
   • Coordination Director (Priority 1)
   • Coordination Manager (Priority 2)
   • Care Coordinator (Priority 3)
   • Coordination Assistant (Priority 4)
3. Result: Everyone in Coordination group can view financial reports

Alternative setup using priority:

1. Create Grant permission: CanViewFinancialReports
2. Assign to: Coordination Assistant (Priority 4 - lowest in group)
3. Result: Due to priority system, all higher roles automatically inherit this permission
4. Benefit: Only need to assign once instead of to each role

FAQ

How do I know what permissions I have?

Your permissions are determined by:

1. Your assigned role(s) - shown in your user profile
2. Any custom permissions added to your account
3. If you're a System Administrator

Contact your administrator if you need to know your specific permissions or if you need access to a feature.

What happens if I have multiple roles?

You receive the combined permissions of all your roles. The system checks all your roles when determining access.

Example:

• You have both "Clinical Director" and "Coordination Manager" roles
• You get permissions from both the Clinical and Coordination groups
• You have the highest priority level from each group

What if a Grant and Restrictive permission conflict?

Restrictive permissions always win. If you have a Restrictive permission that blocks an action, you cannot perform that action, even if a Grant permission says you should have access.

Example:

• Grant permission says "Clinical Director can delete records"
• Restrictive permission says "Cannot delete records older than 1 year"
• Result: You can delete recent records, but NOT records older than 1 year

Can permissions be different for different companies?

Yes! HCM supports multiple companies, and permissions can be configured separately for each company.

Example:

• Company A: "Admin" role has CanApprovePayroll permission
• Company B: "Admin" role does NOT have CanApprovePayroll permission
• Same role, different permissions based on company configuration

How do I request a new permission?

1. Contact your system administrator or manager
2. Explain what feature you need access to and why
3. The administrator can either:
   • Add a custom permission to your user account
   • Request a role change if the permission should be part of your job
   • Request a new permission be created if it doesn't exist

Who can change permissions?

Only System Administrators and users with the CanManageUsers permission can assign roles and permissions to users.

Are permission changes immediate?

Usually yes. When an administrator changes your permissions or roles:

• Most changes take effect immediately
• You may need to refresh your browser or log out and back in to see the changes
• If you don't see expected changes after refreshing, contact your administrator

What's the difference between a role and a permission?

Think of it this way:

• Role = Your job (Clinical Director)
• Permissions = Your job duties (edit records, approve staff, view reports, etc.)

Why can't I access a feature I need?

If you can't access a feature you believe you should have access to:

1. Check your role: Make sure you have the appropriate role for your job
2. Verify the feature requires a permission: Not all features are permission-controlled
3. Contact your administrator:They can:
   • Check if you have the required permission
   • Add the permission if appropriate
   • Explain if there's a business reason you shouldn't have access

What does "Company-specific" mean?

Many organizations using HCM operate multiple companies or divisions. Permissions can be configured differently for each company:

• Your role in Company A might have different permissions than the same role in Company B
• When you switch between companies in HCM, your available permissions may change
• This allows each company to customize access based on their specific needs

Need More Help?

Contact your System Administrator or HCM Support team if you:

• Need a permission explained
• Believe you should have access to a feature but don't
• Need to request a role change
• Have questions about why you can't perform a specific action

For Administrators:
For technical documentation on setting up and managing permissions, see the HCM Administrator Guide or contact HCM Technical Support.

Last Updated: October 2025
Version: 1.0