Workflow escalation not triggering when task deadline passes in workflow-mgmt (aras-13.0)

PLM Aras Innovator
, , , , , , , ,
1

Custom escalation condition in workflow-mgm doesn’t fire when approval tasks exceed our defined SLA thresholds. We’ve configured escalation rules that should notify management when engineering approval tasks remain in pending status for more than 48 hours, but the notifications never trigger.

The escalation rule is set up as a custom condition on the approval activity with a time-based trigger. We’ve defined the overdue task detection logic to check task age against our SLA policy, and the notification templates are configured to email the task owner’s manager and the department head.

Our workflow activities complete normally when users respond within the timeframe, so the basic workflow engine is functioning. However, when tasks sit idle past the 48-hour threshold, the escalation path never executes. We’ve checked the notification service logs and there are no entries for escalation attempts, suggesting the condition itself isn’t evaluating as true even when tasks are clearly overdue.

This is causing missed SLAs across multiple engineering change workflows. Management has no visibility into delayed approvals until someone manually checks task status. Has anyone successfully implemented custom escalation rules with time-based conditions in Aras 12.0 workflow-mgm?

2

The workflow escalation engine in Aras 12.0 runs on a scheduled basis, not continuously. By default, it checks for escalation conditions every 15 minutes. If your escalation condition is technically correct but the evaluation window is too narrow, it might be missed between check cycles. Also verify that the Workflow Escalation Agent service is actually running on your server. You can check this in the Windows Services panel if you’re on Windows, or the equivalent service manager on Linux. If the agent isn’t running, no escalations will ever process.

3

Check if your workflow process has the escalation timer enabled. There’s a specific setting on the workflow definition that controls whether time-based escalations are active. If that’s disabled, no escalation conditions will evaluate regardless of how they’re configured.

4

I checked the workflow definition and the escalation timer is enabled at the process level. The date comparison in my condition uses the workflow task’s created_on date compared to current time, both in UTC. Still no escalations firing. Could there be an issue with how the workflow engine schedules escalation checks?

5

Your workflow escalation issue involves configuration gaps across all three focus areas. Here’s the comprehensive solution:

Custom Escalation Rule Configuration: The escalation rule must be properly defined at the workflow activity level. Navigate to your approval activity in the workflow designer and verify these settings:

  1. Activity Properties > Escalation tab must be enabled
  2. Escalation Type should be set to “Time-Based”
  3. The escalation condition must reference the correct workflow variable or property
  4. Escalation Path must point to a valid escalation activity in your workflow graph

In Aras 12.0, escalation conditions don’t automatically evaluate based on task age. You need to explicitly configure the time threshold. The common mistake is assuming the workflow engine will calculate task age automatically - it won’t. You must create a workflow variable that tracks task start time and compare it to current time in your condition.

Overdue Task Detection Implementation: The escalation condition needs to be structured correctly for time-based evaluation. Here’s the proper approach:

  1. Add a workflow variable: task_start_time (set when activity begins)
  2. Add a workflow variable: escalation_threshold (set to 48 hours in minutes: 2880)
  3. Configure the escalation condition to evaluate:
    • Current Time - task_start_time > escalation_threshold

The workflow escalation agent evaluates these conditions every 15 minutes by default. Your condition must be structured as a boolean expression that the agent can evaluate. Complex logic or method calls in escalation conditions often fail silently.

Critical Configuration: Verify the Workflow Escalation Agent service is running:

  • Windows: Check “Aras Workflow Escalation Agent” in Services
  • Linux: Check workflow_escalation_agent daemon status

If the service isn’t running, escalations will never trigger regardless of configuration.

Notification Template Setup: Your notification templates must be associated with the escalation activity, not the approval activity. Common configuration:

  1. Create an escalation activity in your workflow (separate from approval activity)
  2. Connect approval activity to escalation activity with a transition
  3. Transition condition: task_age > threshold
  4. Escalation activity type: Auto (executes immediately when reached)
  5. Escalation activity action: Send Notification
  6. Configure notification recipients using workflow variables:
    • ${task_owner_manager} for direct manager
    • ${department_head} for department escalation

Complete Solution Architecture:

Your workflow should follow this pattern:

[Approval Activity] → (48hr timeout) → [Escalation Activity] → [Notification]

The escalation activity needs these properties:

  • Activity Type: Auto
  • Execute: Notification Method
  • Method: Send_Escalation_Email
  • Recipients: Derived from task owner’s manager relationship

Implementation Steps:

  1. Add workflow variables for time tracking:

    • task_start_time: Set to current_date() when approval activity begins
    • hours_elapsed: Calculated as (current_date() - task_start_time) / 60

  2. Create escalation activity:

    • Add new activity to workflow graph
    • Set activity type to Auto
    • Configure notification method to use your email template

  3. Add transition from approval to escalation:

    • Condition: hours_elapsed > 48 AND task_status = ‘Pending’
    • Priority: Set higher than normal completion transitions

  4. Configure the escalation timer at workflow process level:

    • Enable “Check Escalations” option
    • Set check interval (default 15 minutes is usually sufficient)

  5. Grant permissions to Workflow Escalation Agent identity:

    • Read access to workflow task properties
    • Read access to user/identity relationships for manager lookup
    • Execute permission on notification methods

Testing Approach:

For immediate testing without waiting 48 hours:

  1. Temporarily reduce escalation threshold to 5 minutes
  2. Start a test workflow and let approval task sit idle
  3. Monitor the escalation agent logs for evaluation attempts
  4. Verify notification is sent after 5 minutes
  5. Once confirmed working, restore 48-hour threshold

Troubleshooting Checklist:

  • Escalation agent service running: Check system services
  • Agent has proper permissions: Verify identity grants
  • Workflow variables initialized: Check workflow instance data
  • Notification templates valid: Test template rendering separately
  • Escalation path connected: Verify workflow graph transitions
  • Time calculations correct: Ensure UTC consistency throughout

The key insight for Aras 12.0 is that escalation isn’t automatic based on task age - you must explicitly model the escalation path as workflow activities with time-based transition conditions. The escalation agent only evaluates these transitions; it doesn’t inherently understand SLA thresholds. By properly structuring your workflow with explicit escalation activities and time-based transitions, your overdue task notifications will trigger reliably whenever approval tasks exceed the 48-hour threshold.

6

We had escalations failing silently because the notification service identity didn’t have permission to read the workflow task properties needed for the escalation condition evaluation. The escalation agent would try to check the condition, fail on permission denial, and just skip that task without logging an error. Check your agent’s identity permissions.