We’re experiencing a critical issue with our compensation approval workflow in Dayforce. Compensation requests are stuck at the manager approval level for over 5 business days with no escalation occurring. The workflow was designed to escalate to the next level after 3 days of inactivity, but it’s simply not happening.
I’ve verified the escalation rules are configured in the workflow designer, and the notification templates appear to be active. However, when I check the audit logs, there’s no record of escalation attempts being triggered. This is causing significant delays in our payroll processing cycle, and we have about 47 requests currently stuck in limbo.
Has anyone encountered similar issues with escalation rule mapping not functioning as expected? I’m particularly concerned about whether the notification template activation might be interfering with the escalation logic, or if there’s something in the audit log review that I’m missing.
Based on your description, this is a multi-layered configuration issue that requires systematic verification of all three focus areas you mentioned.
ESCALATION RULE MAPPING:
First, verify your escalation rules are properly mapped and active. Navigate to Workflow Configuration > Compensation Approval > Escalation Rules. Check that:
- Each escalation level has valid target users or groups assigned
- The escalation sequence follows your organizational hierarchy (Manager > Director > VP)
- No circular references exist in the escalation chain
- All target users have active employment status in the system
Critical: In cd-2022.2, escalation rules must have both a ‘From’ role and a ‘To’ role explicitly defined. If either is null or points to an inactive security role, the escalation silently fails.
NOTIFICATION TEMPLATE ACTIVATION:
The notification template issue is likely your primary blocker. Go to Configuration > Notifications > Escalation Templates and:
- Verify the ‘Compensation Escalation Notice’ template is in ‘Active’ status
- Test the template using the ‘Preview’ function with sample data
- Confirm all merge fields ({{ManagerName}}, {{RequestAmount}}, {{EscalationDate}}) render correctly
- Check that the template is assigned to the correct workflow step in Workflow Designer > Compensation Approval > Step Properties
In your version, there’s a specific bug where if the notification template has HTML rendering errors, it blocks the entire escalation process. Review the template HTML source for any unclosed tags or invalid CSS references.
AUDIT LOG REVIEW:
For the audit trail investigation:
- Go to System Administration > Audit Logs > Workflow Events
- Filter by: Workflow=‘Compensation Approval’, Date Range=Last 30 Days, Event Type=‘Escalation’
- Look for entries with Status=‘Failed’ or ‘Skipped’
- Check the error details column for specific failure reasons
If you see no escalation events at all (not even failed attempts), this confirms the escalation logic isn’t being triggered. This typically indicates:
- The workflow timer service isn’t running (check System Services status)
- The escalation step is disabled at the workflow definition level
- A plan-level override is suppressing escalation
IMMEDIATE ACTION PLAN:
- Verify the Workflow Timer Service is running in System Services
- Check compensation plan settings for workflow overrides (Compensation Management > Plans > [Your Plan] > Workflow Settings)
- Test the escalation notification template and fix any rendering errors
- Review escalation rule mappings for inactive users/groups
- For the 47 stuck requests, you’ll likely need to manually reassign them using Workflow Administration > Bulk Reassignment
The combination of no audit trail and consistent 5-day delays suggests the timer service may not be processing your workflow instances. Check the service logs for any exceptions related to compensation workflows. Let me know what you find in the audit logs and service status.
Another common culprit is the escalation timer configuration. The 3-day timer you mentioned needs to be configured in business days, not calendar days, and it must account for your organization’s holiday calendar. If your workflow timer is set to calendar days but your org calendar has holidays in that window, the escalation won’t trigger until the business day count is met. Review the timer settings in the workflow properties and ensure they align with your business calendar setup.
Have you verified the workflow step permissions? In some cases, if the escalation target role doesn’t have the proper permissions to view or act on compensation requests, the system won’t trigger the escalation. Go to Security > Role Permissions and confirm that the escalation recipient roles have both ‘View Compensation Requests’ and ‘Approve Compensation Requests’ permissions enabled. Missing permissions can cause the escalation logic to skip those steps entirely.
Check your notification template dependencies. In cd-2022.2, there’s a known behavior where if the notification template associated with the escalation step has validation errors or missing placeholders, the entire escalation chain fails silently. Navigate to Configuration > Notifications and test-send the escalation template to verify it renders correctly. Also verify the template is assigned to the correct workflow step in the workflow designer - sometimes they get unmapped during updates.
One more thing to check - workflow version conflicts. If you’ve made recent changes to the workflow definition, existing in-flight requests might still be running on the old workflow version that didn’t have escalation properly configured. Check the workflow instance details for those stuck requests to see which version they’re running on. You might need to manually reassign them or cancel and resubmit to get them on the current workflow version with proper escalation.
I’ve seen this before. The first thing to check is whether your escalation rules are actually mapped to active user groups. Go to Workflow Configuration > Escalation Rules and verify that the target escalation groups have active members. Sometimes the rules look configured but point to empty or inactive groups, which causes silent failures with no audit trail.