This article explains how to diagnose and fix Role and permission issues in Pace Scheduler, including approval routing, schedule-edit access, and inconsistent behavior between web and mobile. Most permission problems are caused by Supervisor Rules scope, but some are product defects that require escalation.

 

Use this guide when users can approve/cancel requests they should not, cannot perform actions they should be allowed to perform, or when permissions appear correct but behavior is inconsistent.

---

Prerequisites

• You have admin access to your site.
• You can access Admin Panel → Supervisor Rules.
• You have at least one affected user example and one control user for comparison.
• You can capture screenshots of the exact action path (especially right-click actions and Pending Requests behavior).
• You know the expected behavior by Role and by subordinate scope.

---

Before you begin

• Confirm where approval access is configured.
  • Approval routing is controlled in Supervisor Rules, not basic employee profile toggles.
  • For first-level approvals, verify request-handling abilities (for example, Handle All 1st Level Requests) in the correct rule.
• Verify exact Role assignments.
  • Role mismatches can cause users to lose or gain permissions unexpectedly.
  • Similar Role names may still map differently in rules.
• Check channel context.
  • Test the same action on web and mobile to identify channel-specific issues.

 

If rules look correct but unauthorized actions still occur, treat this as a possible authorization bug and escalate with reproducible evidence.

---

Steps

Part 1: Validate Supervisor Rule structure

1. Open Supervisor Rules and locate the active rule.
   • Go to Admin Panel → Supervisor Rules.
   • Identify which rule should govern the affected user.
2. Verify who is listed as Supervisors vs Subordinates.
   • Ensure only intended supervisory Roles are in the Supervisors section.
   • Move non-supervisory Roles to Subordinates only.
   • Example fix pattern: remove an unintended Role from Supervisors so peers cannot approve each other.
3. Confirm subordinate scope includes required Roles/groups.
   • If a supervisor cannot edit/approve another user, add the missing subordinate Role/group to the correct rule.
   • Retest as the affected supervisor account.
4. Validate required abilities in the rule.
   • Enable request-handling rights where needed.
   • Enable Create/Modify Extra Shifts when extra-shift control is expected.
   • For self-actions (such as Acting Supervisor workflows), verify Manual Schedule Edits with subordinate scope set to Self when appropriate.

 

Part 2: Prevent self-approval and overbroad routing

5. Disable self-approval where policy requires separation.
   • Edit the relevant supervisor rule and remove self-approval capability.
   • Save and test with a supervisor-submitted request.
6. Create a dedicated approval rule if needed.
   • Use one rule for broad supervision and a separate rule for approval routing.
   • Limit subordinate scope in the approval rule to exact Roles/groups.

 

Part 3: Reproduce and isolate inconsistencies

7. Test the same action in multiple contexts.
   • Test in Pending Requests and in related request-management views.
   • Test with at least two approvers to compare outcomes.
8. Capture full evidence if behavior is inconsistent.
   • Collect screenshots of clicked controls, visible permissions, and resulting status.
   • Include user, Role, rule name, and date/time.
9. Check for operator error before escalation.
   • Confirm the user is using the correct workflow path for the action.
   • If the workflow is incorrect, provide corrected steps and retest.

 

Part 4: Escalate confirmed defects

10. Escalate to development when configuration is correct but behavior is wrong.
    • Examples: unauthorized request cancellation, approval controls failing for many supervisors, web/mobile mismatch for approval permissions, missing shadow removal controls.
    • Include reproducible steps and before/after screenshots.
11. Validate after patch deployment.
    • Retest with the same users and scenarios used in reproduction.
    • Confirm issue is resolved and monitor for recurrence.

---

Confirm it worked

• Only intended supervisory Roles can approve/deny requests.
• Non-supervisors cannot approve/cancel coworkers’ requests.
• Supervisors can act on intended subordinate users/groups.
• Self-approval is blocked where required.
• Web and mobile approval behavior match expected permissions.
• Pending Requests actions behave consistently across approvers.

---

Troubleshooting

• “User can approve requests but should not.”
  • Check whether that Role is incorrectly listed in Supervisors.
  • Move it to Subordinates only and retest.
• “Supervisor cannot edit another supervisor’s schedule.”
  • Add the missing subordinate Role/group to the active supervisor rule.
  • Retest using the affected supervisor account.
• “Works on web, fails on mobile.”
  • Document the same action in both channels.
  • Escalate as a mobile permission propagation issue if rules are correct.
• “Pending Requests behaves differently than expected.”
  • Compare with a second approver and capture both outcomes.
  • Escalate if inconsistent behavior persists with correct rule scope.
• “Permissions page looks broken/missing columns.”
  • Have user sign out/in and reload the page.
  • If still broken, capture browser/version and screenshot for further review.
• “Shadowing remove control is missing.”
  • Confirm the missing control in screenshot evidence.
  • Check for stale/duplicate user records causing corrupted shadow behavior.
  • Escalate and clean invalid records, then re-add valid assignments as needed.

---

FAQ

• Can I grant approval authority from Employee Permissions only?
  No. Use Supervisor Rules for approval routing and subordinate scope.
• What is the safest way to prevent supervisors approving their own requests?
  Remove self-approval from the relevant rule and use a separate approval-specific rule with scoped subordinates.
• Why can two similar users get different outcomes?
  Their Roles or rule scope may differ, even if names appear similar. Verify exact Role assignment and active rule membership.
• When should I escalate to development?
  Escalate when rule configuration is validated, behavior is reproducible, and permission enforcement still fails.