Assignment routing errors in workflow management when custom SLA escalation actions fail

BPM Pega Platform
, , , , , , , ,
1

We’re facing critical assignment routing errors in our Pega 8.6 workflow management system. Assignments are not being routed to the correct work queues when custom SLA escalation actions trigger, resulting in missed escalations and delayed processing.

Our workflow uses custom SLA escalation actions that should reassign work to a supervisor queue when deadlines are breached. The escalation action calls a custom activity that’s supposed to update the assignment routing:


// Current escalation activity logic
pyWorkPage.pxAssignedWorkBasket = "SupervisorQueue";
tools.getWorkPage().updateAssignment();

However, when we check the Activity log in Tracer, we see that the assignment routing logic isn’t executing properly. The work remains in the original queue even after the SLA deadline passes. We’ve verified the work queue configuration in the organizational structure, and the SupervisorQueue exists and is properly configured.

The custom SLA escalation actions are defined at the flow level, and we’re using them to handle time-sensitive cases. Has anyone dealt with similar issues where assignment routing fails during SLA escalation?

2

The code snippet you shared shows a common mistake. You’re trying to update the assignment by directly setting the work basket property and calling a method that doesn’t exist in the standard API. Pega has specific routing activities you should use instead.

Try using the Work-.RouteToWorklist or Work-.TransferAssignment activities instead of custom code. These handle all the routing logic properly including updating work basket references and triggering the necessary events.

3

Thanks for the input. I looked into the standard routing activities, but I’m not clear on which one to use for SLA escalation scenarios. Should I be using RouteToWorklist or TransferAssignment? And how do I properly reference the work queue in these activities?

4

Let me provide a comprehensive solution for fixing assignment routing errors during custom SLA escalation actions in Pega workflow management.

Understanding the Core Problem: Your current approach tries to manually manipulate assignment properties, which bypasses Pega’s assignment routing framework. This causes the routing logic to fail because the necessary internal updates and event triggers aren’t executed.

Proper SLA Escalation Configuration:

1. Custom SLA Escalation Actions - Correct Implementation: Replace your custom activity code with the standard Pega routing activity:


// Use Work-.TransferAssignment activity
Param.WorkBasket = "SupervisorQueue"
Param.TransferReason = "SLA Escalation"
Call Work-.TransferAssignment

This ensures proper assignment routing logic is executed, including work queue updates and operator notifications.

2. Work Queue Configuration Verification: In your organizational structure, confirm:

  • The work queue “SupervisorQueue” is defined under the correct organization unit
  • The queue has active operators assigned with appropriate skills
  • The workbasket name matches exactly (case-sensitive) in your escalation activity
  • Access rules allow the escalation process to route work to this queue

3. SLA Rule Configuration: In your flow’s assignment shape, verify the SLA escalation setup:

  • Navigate to the assignment shape > Service Level tab
  • Under “Escalation Actions”, ensure your custom action is set to “Run Activity”
  • The activity should run in the context of the assignment (not background)
  • Set the correct privilege level if your activity needs elevated permissions
  • Verify the timing - deadline vs. goal time for when escalation should trigger

4. Assignment Routing Logic - Alternative Approach: If you need more control over the routing decision, create a decision table or when rule that determines the target queue based on case properties:


// In your escalation activity:
Param.TargetQueue = @GetRoutingQueue()
Param.TransferReason = "SLA Breach"
Call Work-.TransferAssignment

Where @GetRoutingQueue() is a custom function that implements your business logic for queue selection.

5. Tracer Analysis for Troubleshooting: When testing, use Tracer to monitor:

  • The SLA rule evaluation events (look for “SLA deadline reached”)
  • The escalation action execution (verify the activity is called)
  • The Work-.TransferAssignment activity execution
  • Any authorization or privilege errors
  • The final assignment update events

6. Common Pitfalls to Avoid:

  • Don’t use pxAssignedWorkBasket directly - it’s a read-only display property
  • Don’t create custom routing logic that bypasses standard activities
  • Ensure operators in the target queue have the right access group and skills
  • Verify that the SLA escalation action has “Run immediately” enabled if time-critical

7. Testing Your Fix: Create a test scenario:

  • Set a very short SLA deadline (e.g., 1 minute) for testing
  • Create a test case and let it sit without processing
  • Monitor in Tracer when the deadline is reached
  • Verify the assignment moves to the SupervisorQueue
  • Check that supervisor operators can see and open the assignment

Best Practice Recommendation: Instead of custom activities for standard routing operations, leverage Pega’s built-in assignment routing framework. Use Work-.TransferAssignment for escalations, and configure your work queue structure properly in the organizational hierarchy. This ensures all routing logic, notifications, and audit trails are handled correctly by the platform.

The key fix is replacing your manual property updates with the standard Work-.TransferAssignment activity and ensuring your work queue configuration is correct. This will resolve the routing errors and ensure proper assignment escalation when SLA deadlines are breached.

5

For SLA escalations that need to route to a different work queue, use Work-.TransferAssignment. This activity handles the complete transfer including updating the assignment status and work basket references.

You’ll need to pass the work basket name as a parameter. Make sure you’re using the correct organizational structure reference - it should match exactly what’s configured in your Org structure rules. Also verify that the operators in the target queue have the appropriate skills and access rights to work on these assignments.

6

One more thing to check - your SLA escalation action configuration. In the flow, when you define the escalation action, there’s a section for ‘Action Type’. Make sure you’re using ‘Run Activity’ and not ‘Send Email’ or another action type. The activity should be set to run in the context of the assignment, not as a background job.

7

I agree with the previous comment. Also check if your custom escalation action is configured to run in the correct context. SLA escalation actions need to have proper access to the assignment object. If the action is running in a different thread or context, it might not have the right permissions to update the assignment routing.

Another thing - verify that your SLA rule is actually triggering. Sometimes the issue isn’t with the routing logic but with the SLA configuration itself. Check the deadline and goal times to ensure they’re set correctly.