Back to All Guides
Access Control

Manager Permissions & Access Control

Complete guide to configuring granular permissions for multi-manager organizations. Control shift creation, approvals, employee management, and location access. Restrict managers to specific locations with 13 permission flags for secure access control.

12 min read
HEAD_MANAGER Only
Multi-Manager Organizations

Understanding Manager Permissions

Permission system overview and access levels

What Are Manager Permissions?

  • Manager Permissions is a granular access control system for multi-manager organizations
  • Allows HEAD_MANAGERS to restrict what each MANAGER role can see and do
  • Controls both what actions managers can perform and what data they can access
  • Two Types of Restrictions:
  • 1. Location Scope (What managers can see):
  • - Unrestricted: Manager sees all employees, shifts, and requests across all locations
  • - Location-Restricted: Manager only sees employees/shifts for assigned locations
  • - Example: "Manager A" only manages "Downtown" location, cannot see "Uptown" data
  • 2. Permission Flags (What managers can do):
  • - Control specific actions: create shifts, approve time-off, edit employees, export payroll
  • - Each permission can be enabled/disabled individually
  • - 13 granular permissions available (detailed below)
  • Who Can Configure Permissions:
  • - Only HEAD_MANAGER role can view and modify manager permissions
  • - Regular MANAGER role cannot change permissions
  • - HEAD_MANAGERS have full access regardless of restrictions (cannot be limited)
  • Default Behavior (Backward Compatibility):
  • - All permissions default to TRUE when first created
  • - Managers have full access until explicitly restricted
  • - No ManagerPermissions record = full access
  • - This preserves existing behavior for organizations not using restrictions

Accessing Manager Permissions

  • Navigation Path:
  • 1. Log in as HEAD_MANAGER
  • 2. Click Settings in sidebar
  • 3. Click "Manager Permissions" section
  • 4. View list of all managers in organization
  • Page Structure:
  • - Header with description
  • - Master toggle: Enable/disable all restrictions
  • - Info banner when restrictions are active
  • - List of managers with current permissions summary
  • - "Configure" button for each manager
  • Manager List Displays:
  • - Manager name and email
  • - Permission template badge (if assigned)
  • - Assigned departments (green badges)
  • - Assigned locations (purple badges)
  • - Permission summary (checkmarks for enabled permissions)
  • If No Managers Exist:
  • - Empty state message: "No managers found"
  • - Instruction to promote employees to Manager role first

Master Restrictions Toggle

  • Location: Top of Manager Permissions page
  • Purpose:
  • - Quick enable/disable for entire restriction system
  • - When ENABLED: Managers only see their assigned scope
  • - When DISABLED: All managers see all data (current default behavior)
  • Toggle States:
  • ENABLED State:
  • - Blue toggle switch
  • - Badge: "✓ Restrictions Active - Managers see only their scope"
  • - Info banner displays location-based restriction notice
  • - Manager list shows assigned locations/departments
  • - System enforces location scope on all manager actions
  • DISABLED State:
  • - Gray toggle switch
  • - No restriction badge
  • - All managers have unrestricted access
  • - Location scopes ignored (even if configured)
  • - Backward compatible with organizations not using restrictions
  • Important Notes:
  • - Toggle is UI-only currently (not persisted to database)
  • - Shows alert when toggled: "Manager restrictions enabled/disabled (UI only - not saved)"
  • - Future enhancement: Persist toggle state to org settings
  • - Does NOT affect HEAD_MANAGER access (always full access)

Location-Based Restrictions

Control which locations managers can access

How Location Scoping Works

  • Location Scope determines WHAT DATA managers can see and manage
  • Two Modes:
  • 1. canManageAllLocations = TRUE (Unrestricted):
  • - Manager sees all employees across all locations
  • - Can create/edit/delete shifts at any location
  • - Sees all time-off requests and shift trades
  • - Access to all reports and analytics
  • - Default mode for backward compatibility
  • 2. canManageAllLocations = FALSE (Location-Restricted):
  • - Manager only sees employees assigned to their locations
  • - Can only create shifts at assigned locations
  • - Only sees time-off/trades from employees at their locations
  • - Reports filtered to assigned locations only
  • - Must have at least one location assigned
  • Data Model:
  • - ManagerPermissions.canManageAllLocations (boolean)
  • - ManagerLocationScope table stores assigned locations
  • - Many-to-many relationship: One manager can have multiple locations
  • Database Structure:
  • - ManagerLocationScope has:
  • * managerId (which manager)
  • * locationId (which location they can access)
  • * Unique constraint prevents duplicates
  • * Cascade delete when manager or location removed
  • Security:
  • - System automatically enforces location restrictions
  • - Managers cannot access data from unauthorized locations
  • - All actions are limited to their assigned locations

Assigning Locations to Managers

  • Configuration Process:
  • 1. Navigate to Manager Permissions page
  • 2. Click "Configure" button for specific manager
  • 3. In configuration modal/page:
  • - Toggle "Manage All Locations" switch OFF
  • - Location selector appears
  • - Select one or more locations from dropdown
  • - Dropdown shows all active locations in organization
  • 4. Click "Save" to apply changes
  • Validation Rules:
  • - When restricted (canManageAllLocations = false):
  • * Must select at least one location
  • * Error if locationIds array is empty
  • * All locationIds must exist and be active
  • * All locations must belong to same organization
  • - When unrestricted (canManageAllLocations = true):
  • * Location selections ignored
  • * Existing ManagerLocationScope records deleted
  • * Manager gets full access to all locations
  • Effect on Manager Experience:
  • - Immediately filters their dashboard view
  • - Employee list shows only employees at assigned locations
  • - Schedule shows only shifts at assigned locations
  • - Time-off/trades filtered to assigned locations
  • - Analytics/reports scoped to assigned locations

Location Scope Examples

  • Example 1: Single-Location Manager
  • Scenario:
  • - Organization has 3 locations: Downtown, Uptown, Suburbs
  • - "Manager Sarah" should only manage Downtown location
  • Configuration:
  • - canManageAllLocations: false
  • - locationScopes: [Downtown]
  • Result:
  • - Sarah sees only employees assigned to Downtown
  • - Can create shifts only at Downtown location
  • - Sees time-off requests only from Downtown employees
  • - Reports show only Downtown data
  • - Cannot see or modify Uptown or Suburbs data
  • Example 2: Multi-Location Manager
  • Scenario:
  • - Organization has 5 locations
  • - "Manager John" oversees Downtown and Uptown (city locations)
  • - Another manager handles suburban locations
  • Configuration:
  • - canManageAllLocations: false
  • - locationScopes: [Downtown, Uptown]
  • Result:
  • - John sees employees from both Downtown AND Uptown
  • - Can create shifts at either location
  • - Sees time-off from employees at both locations
  • - Analytics combine data from both locations
  • - Cannot access suburban location data
  • Example 3: Unrestricted Manager (Default)
  • Scenario:
  • - "Manager Lisa" is senior manager who needs full visibility
  • - Should see all locations for oversight
  • Configuration:
  • - canManageAllLocations: true
  • - locationScopes: [] (empty, ignored)
  • Result:
  • - Lisa sees ALL employees across ALL locations
  • - Can create/edit shifts at any location
  • - Full access to all time-off and shift trades
  • - Complete organization-wide reporting
  • - Same access as HEAD_MANAGER (except can't change settings)

Permission Flags (Action Control)

Granular control over what actions managers can perform

Shift Management Permissions

  • Three separate permissions control shift operations:
  • 1. canCreateShifts (default: true)
  • Controls: Ability to create new shifts
  • When ENABLED:
  • - Manager can click "Create Shift" button
  • - Can access shift creation form
  • - Can create individual shifts
  • - Can create recurring shifts
  • - Can use AI Copilot schedule generation
  • When DISABLED:
  • - "Create Shift" button still visible but disabled
  • - Clicking it shows: "You don't have permission to create shifts"
  • - Cannot create shifts
  • - Can still VIEW existing shifts
  • Use Cases:
  • - Junior managers who should only edit existing schedules
  • - Approval-only managers who review but don't create
  • - Read-only oversight managers
  • 2. canEditShifts (default: true)
  • Controls: Ability to modify existing shifts
  • When ENABLED:
  • - Can click "Edit" on shift cards
  • - Can modify shift times, locations, requirements
  • - Can assign/unassign employees
  • - Can change shift status (draft, published, cancelled)
  • When DISABLED:
  • - Edit actions blocked with permission error
  • - Cannot modify shift details
  • - Cannot reassign employees
  • - Can still VIEW shift details
  • Use Cases:
  • - Managers who should only view published schedules
  • - Approval-flow where only senior managers edit
  • - Audit/oversight roles
  • 3. canDeleteShifts (default: true)
  • Controls: Ability to remove shifts from schedule
  • When ENABLED:
  • - "Delete" button visible on shift cards
  • - Can remove individual shifts
  • - Can bulk-delete multiple shifts
  • - Warning prompt before deletion
  • When DISABLED:
  • - Delete attempts show: "Insufficient permissions to delete shifts"
  • - Cannot remove shifts
  • - Can mark shifts as cancelled instead
  • Use Cases:
  • - Prevent accidental shift deletion
  • - Require senior approval for schedule changes
  • - Audit trail preservation

Approval Authority Permissions

  • Three permissions control manager approval authority:
  • 1. canApproveTimeOff (default: true)
  • Controls: Ability to approve employee time-off requests
  • When ENABLED:
  • - "Approve" button visible on PTO requests
  • - Can approve vacation, sick leave, personal time
  • - Can add approval comments
  • - Request changes to APPROVED status
  • When DISABLED:
  • - Approval attempts blocked with permission error
  • - Can VIEW requests but cannot approve
  • - Must escalate to authorized manager
  • Use Cases:
  • - Junior managers who submit to senior for approval
  • - Department-specific approval chains
  • - HR-only time-off approval workflow
  • 2. canDenyTimeOff (default: true)
  • Controls: Ability to deny employee time-off requests
  • When ENABLED:
  • - "Deny" button visible on PTO requests
  • - Can reject time-off with reason
  • - Must provide denial comment (required)
  • - Request changes to DENIED status
  • When DISABLED:
  • - Deny attempts blocked with permission error
  • - Cannot reject requests
  • - Can only approve or leave pending
  • Use Cases:
  • - Positive-only managers (approve-only, never deny)
  • - Escalation workflow (denials require senior approval)
  • - Prevent manager conflicts with employees
  • 3. canApproveShiftTrades (default: true)
  • Controls: Ability to approve shift swap/trade requests
  • When ENABLED:
  • - Can approve shift swap requests
  • - Can approve shift drops and pickups
  • - "Approve Trade" button visible
  • When DISABLED:
  • - Trade approval attempts show permission error
  • - Shift trades remain in PENDING status
  • - Must escalate to authorized manager
  • Use Cases:
  • - Senior managers only approve sensitive shifts
  • - Automatic approval mode (no manager needed)
  • - Oversight managers who don't handle day-to-day trades
  • Important Notes:
  • - Approval permissions work together with shift trade approval mode
  • - If org has AUTO_APPROVE mode, this permission is bypassed
  • - If MANAGER_APPROVAL required, this permission must be enabled
  • - CONDITIONAL mode checks this permission + role requirements

Employee Management Permissions

  • Two permissions control employee data management:
  • 1. canEditEmployeeProfiles (default: true)
  • Controls: Ability to modify employee information
  • When ENABLED:
  • - "Edit" button visible on employee profiles
  • - Can modify: name, email, phone, address
  • - Can change: role assignments, departments, locations
  • - Can update: hire date, hourly rate, emergency contacts
  • - PUT /api/orgs/{orgId}/employees/{employeeId} allowed
  • When DISABLED:
  • - Edit attempts show: "You don't have permission to edit employee profiles"
  • - Profile pages are read-only
  • - Cannot modify any employee data
  • - Can still VIEW employee profiles
  • Scope Interaction:
  • - If location-restricted: Can only edit employees at assigned locations
  • - If unrestricted: Can edit all employees (if permission enabled)
  • - Permission + scope both must allow access
  • Use Cases:
  • - Read-only managers who view but don't modify
  • - HR-only employee data management
  • - Junior managers who cannot change employee details
  • - Audit/compliance roles
  • 2. canCreateEmployees (default: true)
  • Controls: Ability to add new employees to organization
  • When ENABLED:
  • - "Add Employee" button visible
  • - Can access employee creation form
  • - Can onboard new hires
  • - Can invite users via email
  • When DISABLED:
  • - Add employee attempts show: "You don't have permission to create employees"
  • - Creation form inaccessible
  • - Cannot add new employees
  • - Must request HR or senior manager to add
  • Scope Interaction:
  • - If location-restricted: New employees automatically assigned to manager's locations
  • - Cannot create employees for unauthorized locations
  • - Must have at least one location in scope
  • Use Cases:
  • - Centralized HR onboarding process
  • - Prevent unauthorized hiring
  • - Senior manager approval required for new hires
  • - Seasonal hiring control

Organization Management Permissions

  • Four permissions control organization-wide features:
  • 1. canCreateAnnouncements (default: true)
  • Controls: Ability to post team-wide announcements
  • When ENABLED:
  • - "Create Announcement" button visible
  • - Can post announcements to all employees
  • - Can edit/delete own announcements
  • When DISABLED:
  • - Creation attempts blocked with permission error
  • - Cannot post announcements
  • - Can VIEW announcements from others
  • Use Cases:
  • - Senior managers only for official communications
  • - HR/leadership announcement control
  • - Prevent spam or unauthorized messaging
  • 2. canCreateGroupChats (default: true)
  • Controls: Ability to create team group chat rooms
  • When ENABLED:
  • - "New Group Chat" button visible
  • - Can create group conversations
  • - Can add members to groups
  • - Can name and manage groups
  • When DISABLED:
  • - Group creation attempts blocked with permission error
  • - Can participate in existing groups
  • - Cannot create new group chats
  • - 1-on-1 messaging still allowed
  • Use Cases:
  • - Controlled team communication
  • - Prevent excessive group creation
  • - HR/leadership manage official channels
  • 3. canExportPayrollData (default: true)
  • Controls: Ability to export payroll/timesheet reports
  • When ENABLED:
  • - "Export Payroll" button visible
  • - Can download CSV/ADP format exports
  • - Can access time tracking exports
  • - Can see employee hours and wage data
  • When DISABLED:
  • - Export attempts show: "You don't have permission to export payroll data"
  • - Cannot download payroll data
  • - Can still view hours (but not export)
  • Security Implications:
  • - Payroll data includes sensitive wage information
  • - Should be restricted to HR/accounting managers only
  • - Prevents data leakage or wage disclosure
  • Use Cases:
  • - HR-only payroll processing
  • - Accounting department exclusive access
  • - Compliance with wage privacy regulations
  • - Prevent salary information disclosure
  • 4. canSaveShiftTemplates (default: true)
  • Controls: Ability to save schedule as reusable templates
  • When ENABLED:
  • - "Save as Template" button visible
  • - Can create schedule templates
  • - Can apply templates to new weeks
  • When DISABLED:
  • - Template save attempts blocked with permission error
  • - Cannot create templates
  • - Can apply existing templates (if created by others)
  • Use Cases:
  • - Senior managers create templates
  • - Junior managers apply pre-made templates
  • - Standardized scheduling control
  • - Prevent template proliferation
  • All Four Permissions:
  • - Affect organization-wide operations
  • - Not location-specific (apply to entire org)
  • - Often reserved for senior management
  • - Combine with location scope for granular control

Configuring Manager Permissions

Step-by-step permission configuration

How to Configure Permissions (UI Walkthrough)

  • Step 1: Navigate to Manager Permissions
  • - Log in as HEAD_MANAGER
  • - Click "Settings" in sidebar
  • - Click "Manager Permissions" section
  • - Page loads with list of all managers
  • Step 2: Select Manager to Configure
  • - Find manager in list by name or email
  • - Review current permissions summary
  • - Click "Configure" button on their card
  • - Individual configuration page/modal opens
  • Step 3: Configure Location Scope
  • - Toggle "Manage All Locations" switch:
  • * ON = Manager sees all locations (unrestricted)
  • * OFF = Manager restricted to selected locations
  • - If restricted (toggle OFF):
  • * Location selector dropdown appears
  • * Select one or more locations
  • * Must select at least one location
  • * Manager will only see employees/shifts at these locations
  • - If unrestricted (toggle ON):
  • * Location selector hidden
  • * Manager gets full access to all current and future locations
  • Step 4: Configure Shift Management Permissions
  • - Three checkboxes:
  • ☐ Can Create Shifts
  • ☐ Can Edit Shifts
  • ☐ Can Delete Shifts
  • - Check/uncheck based on manager responsibilities
  • - All default to checked (enabled)
  • - Uncheck to revoke that specific permission
  • Step 5: Configure Approval Authority
  • - Three checkboxes:
  • ☐ Can Approve Time-Off Requests
  • ☐ Can Deny Time-Off Requests
  • ☐ Can Approve Shift Trades
  • - Control manager approval powers
  • - Can allow approve but not deny (positive-only)
  • - Can restrict trade approvals to senior managers
  • Step 6: Configure Employee Management
  • - Two checkboxes:
  • ☐ Can Edit Employee Profiles
  • ☐ Can Create New Employees
  • - Restrict employee data changes to HR
  • - Control who can onboard new hires
  • Step 7: Configure Organization Features
  • - Four checkboxes:
  • ☐ Can Create Announcements
  • ☐ Can Create Group Chats
  • ☐ Can Export Payroll Data
  • ☐ Can Save Shift Templates
  • - Control sensitive org-wide features
  • - Restrict payroll export to HR/accounting
  • - Limit announcements to leadership
  • Step 8: Save Configuration
  • - Click "Save Permissions" button
  • - API validates all inputs:
  • * Ensures manager exists and has MANAGER role
  • * Validates selected locations belong to org
  • * Checks at least one location if restricted
  • - If validation passes:
  • * ManagerPermissions record created/updated
  • * ManagerLocationScope records updated
  • * Success message displayed
  • * Permissions take effect immediately
  • - If validation fails:
  • * Error message displayed
  • * No changes saved
  • * User must fix errors and retry
  • Step 9: Verify Changes
  • - Return to manager list
  • - Verify permission summary updated
  • - Check location badges display correctly
  • - Optional: Log in as that manager to test restrictions

Resetting Permissions to Default

  • To Remove All Restrictions and Restore Full Access:
  • Option 1: Via UI
  • 1. Go to Manager Permissions page
  • 2. Click "Configure" for the manager
  • 3. Toggle "Manage All Locations" to ON
  • 4. Check ALL permission checkboxes
  • 5. Click "Save"
  • - Result: Manager has full access (same as default)
  • Effect of Resetting:
  • - All permission restrictions are removed
  • - All location restrictions are removed
  • - Manager gets full access to everything
  • - Changes take effect immediately
  • Note:
  • - Resetting is permanent - you'll need to reconfigure if you want restrictions again
  • - Only HEAD_MANAGER can reset permissions
  • - The manager will see all locations and have all permissions enabled

How Permissions Work

Understanding how permissions are enforced

How Restrictions Are Enforced

  • When you disable a permission for a manager, here's what happens:
  • The System Automatically:
  • - Shows only data they're allowed to see (filters lists)
  • - Blocks restricted actions when attempted
  • - Displays error messages like "You don't have permission" when they try
  • - Prevents unauthorized changes from being saved
  • What Managers Will See:
  • Schedule Page:
  • - If "Create Shifts" is disabled: Clicking "Create Shift" shows permission error
  • - If "Edit Shifts" is disabled: Edit attempts show permission error
  • - If "Delete Shifts" is disabled: Delete attempts show permission error
  • - If restricted to specific locations: Only see shifts at their locations
  • Employee Management:
  • - If "Add Employees" is disabled: Add attempts show permission error
  • - If "Edit Profiles" is disabled: Edit attempts show permission error
  • - If restricted to locations: Only see employees at their locations
  • Time-Off Requests:
  • - If "Approve Time-Off" is disabled: Approval attempts show permission error
  • - If "Deny Time-Off" is disabled: Deny attempts show permission error
  • - If restricted to locations: Only see requests from their location employees
  • Reports & Payroll:
  • - If "Export Payroll" is disabled: Export attempts show permission error
  • - All data automatically filtered to their allowed locations
  • Security Notes:
  • - Permissions are enforced by the system, not just the interface
  • - Managers cannot bypass restrictions
  • - HEAD_MANAGER role always has full access (cannot be restricted)
  • - Changes to permissions take effect immediately

Default Behavior

  • Important: All Permissions Are ENABLED by Default
  • What This Means:
  • - New managers start with full access
  • - Existing managers keep their current access
  • - You must actively disable permissions to restrict access
  • - If you don't configure anything, managers have no restrictions
  • Why It Works This Way:
  • - Ensures nothing breaks when adding managers
  • - You can roll out restrictions gradually
  • - Mix of restricted and unrestricted managers is supported
  • - Easy to start permissive and tighten access over time
  • Special Cases:
  • HEAD_MANAGER Role:
  • - Always has full access to everything
  • - Cannot be restricted with permissions
  • - Bypasses all permission checks
  • - At least one HEAD_MANAGER required per organization
  • When Managers Are Promoted/Demoted:
  • - Promoted to HEAD_MANAGER: Gets full access automatically
  • - Demoted from HEAD_MANAGER: Previous restrictions apply (if any)
  • - Configure permissions before demoting from HEAD_MANAGER
  • When Locations Are Deleted:
  • - Manager loses access to that location automatically
  • - If it was their only location: They lose all access
  • - Reassign managers to other locations before deleting locations

Common Scenarios & Best Practices

Real-world permission configurations

Scenario 1: Junior Manager (Limited Access)

  • Use Case:
  • - New manager learning the system
  • - Should have visibility but limited modification rights
  • - Senior manager reviews their changes
  • Recommended Configuration:
  • Location Scope:
  • - canManageAllLocations: false
  • - Assigned Locations: Their primary location only
  • - Example: If managing "Downtown Store", only assign that location
  • Shift Management:
  • ✓ canCreateShifts: true (let them practice)
  • ✓ canEditShifts: true (modify existing schedules)
  • ✗ canDeleteShifts: false (prevent accidental deletions)
  • Approval Authority:
  • ✗ canApproveTimeOff: false (escalate to senior)
  • ✗ canDenyTimeOff: false (escalate to senior)
  • ✗ canApproveShiftTrades: false (escalate to senior)
  • Employee Management:
  • ✓ canEditEmployeeProfiles: true (update contact info)
  • ✗ canCreateEmployees: false (HR handles onboarding)
  • Organization Features:
  • ✗ canCreateAnnouncements: false (senior managers only)
  • ✓ canCreateGroupChats: true (team communication)
  • ✗ canExportPayrollData: false (sensitive data)
  • ✓ canSaveShiftTemplates: true (learn template workflow)
  • Benefits:
  • - Learns system safely
  • - Cannot make irreversible changes
  • - Escalates important decisions
  • - Gradual responsibility increase
  • Upgrade Path:
  • - After 3-6 months: Enable approval permissions
  • - After 1 year: Enable delete shifts
  • - Eventually: Unrestrict to multiple locations

Scenario 2: Multi-Location Manager (Regional Oversight)

  • Use Case:
  • - Experienced manager overseeing multiple locations
  • - Regional manager for city stores
  • - Should have full control over their locations only
  • Recommended Configuration:
  • Location Scope:
  • - canManageAllLocations: false
  • - Assigned Locations: All locations in their region
  • - Example: "Downtown Store", "Midtown Store", "Uptown Store"
  • - Excludes: Suburban locations managed by other regional managers
  • Shift Management:
  • ✓ canCreateShifts: true
  • ✓ canEditShifts: true
  • ✓ canDeleteShifts: true
  • - Full control over scheduling at their locations
  • Approval Authority:
  • ✓ canApproveTimeOff: true
  • ✓ canDenyTimeOff: true
  • ✓ canApproveShiftTrades: true
  • - Final approval authority for their region
  • Employee Management:
  • ✓ canEditEmployeeProfiles: true
  • ✓ canCreateEmployees: true
  • - Can hire and manage employees at their locations
  • Organization Features:
  • ✓ canCreateAnnouncements: true (region-wide)
  • ✓ canCreateGroupChats: true
  • ✗ canExportPayrollData: false (HR handles payroll)
  • ✓ canSaveShiftTemplates: true
  • Benefits:
  • - Autonomous region management
  • - Clear boundaries (cannot affect other regions)
  • - Scalable as company expands
  • - Data isolation for reporting
  • Reporting Impact:
  • - Analytics show only their 3 locations
  • - Reports aggregate across their region
  • - Cannot see other region metrics (data privacy)

Scenario 3: HR Manager (Employee-Focused)

  • Use Case:
  • - HR/People Operations manager
  • - Handles employee onboarding, profiles, payroll
  • - Does not manage day-to-day schedules
  • Recommended Configuration:
  • Location Scope:
  • - canManageAllLocations: true
  • - Needs visibility across all locations for HR tasks
  • Shift Management:
  • ✗ canCreateShifts: false (operations handles scheduling)
  • ✗ canEditShifts: false
  • ✗ canDeleteShifts: false
  • - Read-only access to schedules (for reference)
  • Approval Authority:
  • ✓ canApproveTimeOff: true (HR approves PTO)
  • ✓ canDenyTimeOff: true
  • ✗ canApproveShiftTrades: false (operations decision)
  • Employee Management:
  • ✓ canEditEmployeeProfiles: true (HR maintains profiles)
  • ✓ canCreateEmployees: true (HR handles onboarding)
  • Organization Features:
  • ✓ canCreateAnnouncements: true (company-wide HR notices)
  • ✗ canCreateGroupChats: false (operations manages teams)
  • ✓ canExportPayrollData: true (HR processes payroll)
  • ✗ canSaveShiftTemplates: false (not schedule manager)
  • Benefits:
  • - Focused on employee lifecycle
  • - Cannot accidentally modify schedules
  • - Full visibility for HR reporting
  • - Payroll export access for processing
  • Workflow:
  • - Onboards new hires
  • - Maintains employee data
  • - Approves PTO requests
  • - Exports payroll for processing
  • - Posts HR announcements

Scenario 4: Read-Only Manager (Oversight Role)

  • Use Case:
  • - Executive oversight
  • - Audit/compliance manager
  • - Training manager observing operations
  • - Consultant reviewing processes
  • Recommended Configuration:
  • Location Scope:
  • - canManageAllLocations: true
  • - Full visibility for oversight
  • Shift Management:
  • ✗ canCreateShifts: false
  • ✗ canEditShifts: false
  • ✗ canDeleteShifts: false
  • - View-only access to schedules
  • Approval Authority:
  • ✗ canApproveTimeOff: false
  • ✗ canDenyTimeOff: false
  • ✗ canApproveShiftTrades: false
  • - Cannot interfere with approvals
  • Employee Management:
  • ✗ canEditEmployeeProfiles: false
  • ✗ canCreateEmployees: false
  • - Read-only employee directory
  • Organization Features:
  • ✗ canCreateAnnouncements: false
  • ✗ canCreateGroupChats: false
  • ✗ canExportPayrollData: false (unless needed for audit)
  • ✗ canSaveShiftTemplates: false
  • Benefits:
  • - Complete visibility
  • - Zero risk of accidental changes
  • - Can review and report
  • - Cannot disrupt operations
  • Use Cases:
  • - Executive reviews staffing levels
  • - Auditor examines schedule compliance
  • - Consultant analyzes efficiency
  • - Trainer observes manager workflows

Best Practices Summary

  • 1. Start Restrictive, Expand Gradually:
  • - New managers: Limited permissions
  • - Prove competence: Expand access
  • - Prevents costly mistakes during training
  • 2. Match Permissions to Job Function:
  • - Operations managers: Full shift control, no payroll
  • - HR managers: Employee/payroll access, no scheduling
  • - Regional managers: Full control within locations
  • - Executives: Read-only oversight
  • 3. Location Scope for Data Privacy:
  • - Franchise locations: Isolate by franchisee
  • - Departments: Separate by business unit
  • - Regions: Prevent cross-region visibility
  • - Compliance: Restrict access to sensitive data
  • 4. Payroll Export Restriction (Critical):
  • - Contains sensitive wage information
  • - Limit to HR and accounting only
  • - Legal compliance (wage privacy)
  • - Prevent data leakage
  • 5. Approval Authority Separation:
  • - Consider separating approve and deny permissions
  • - Positive-only managers (approve but not deny)
  • - Escalation workflow (deny requires senior approval)
  • - Reduces manager-employee friction
  • 6. Document Permission Rationale:
  • - Keep notes on why each manager has their configuration
  • - Review quarterly and adjust as roles change
  • - Helps with onboarding new HEAD_MANAGERs
  • 7. Test Before Applying:
  • - Configure test manager account first
  • - Verify restrictions work as expected
  • - Then apply to production managers
  • 8. Communication is Key:
  • - Inform managers before restricting access
  • - Explain why restrictions are necessary
  • - Provide escalation path for restricted actions
  • 9. Regular Audits:
  • - Review permissions quarterly
  • - Remove access from terminated managers
  • - Update when roles change
  • - Ensure least-privilege principle
  • 10. Emergency Override Process:
  • - HEAD_MANAGER can always bypass restrictions
  • - Document process for temporary permission grants
  • - Have backup HEAD_MANAGER for coverage

Ready to Configure Manager Permissions?

Secure your multi-manager organization with granular access control. Log in as HEAD_MANAGER to start configuring permissions.

Manager Permissions & Access Control for Multi-Manager Teams | XShift AI