Approval workflow in approval-mgmt stalls at manager level after approval action is taken in TC 12.3

We’re experiencing a critical issue with our part release approval workflow in TC 12.3. The workflow consistently stalls when it reaches the manager approval stage. The task appears in the manager’s inbox but doesn’t progress even after approval action is taken.

I’ve checked the workflow escalation rules in Workflow Designer and they seem configured correctly with a 48-hour timeout. The notification server appears to be running, but I’m wondering if there’s an issue with our custom EPM handler that was deployed last month for automated notifications.

This is blocking 15+ part releases and causing significant delays in our product development cycle. Has anyone encountered similar behavior with approval workflows getting stuck at specific stages?

Based on all the symptoms you’ve described, here’s a systematic solution that addresses the workflow escalation rules, notification server issues, and custom handler deployment:

1. Notification Server Resolution: First, stabilize your notification service. Check tc_profilevars for these settings:


notification.server.enabled=true
notification.server.timeout=30000
notification.queue.maxSize=1000

If the queue is backed up, clear it using the notification management utility in BMIDE or restart the notification server service. This resolves the timeout warnings you’re seeing in the logs.

2. Custom Handler Fix: Your EPM handler likely has a hard dependency on notifications. Review the handler code and wrap any notification calls in try-catch blocks so failures don’t block workflow progression. If the handler is calling NotificationService.sendNotification(), make it asynchronous or handle exceptions gracefully:

try {
    NotificationService.send(notification);
} catch (Exception e) {
    logger.warn("Notification failed, continuing workflow");
}

3. Workflow Escalation Rules: Your escalation rules are configured but not triggering because the workflow is in a fault state. After fixing the handler, re-test the escalation by:

  • Opening Workflow Designer
  • Navigate to your approval process template
  • Edit the manager approval task node
  • Verify the escalation path points to a valid backup approver or auto-approval action
  • Set the escalation condition to “Task Not Completed” with your 48-hour duration
  • Save and re-deploy the workflow template

4. Handler Re-deployment: Since the handler was deployed last month, ensure it’s properly registered:

  • Export the workflow template to XML
  • Verify the handler class name matches your deployed JAR
  • Check that all handler arguments are correctly specified
  • Re-deploy the template using workflow_template_deploy utility
  • Restart the Workflow Server service

5. Testing and Validation: Create a test workflow instance with a single manager approval stage. Monitor the server logs during execution. You should see successful handler execution without notification timeouts. Once validated, abort the stalled workflow instances (they’re in a corrupted state) and have users resubmit for approval.

The root cause is your custom handler failing due to notification service instability, which prevents the workflow from advancing even though the approval action is recorded. The escalation rules can’t trigger because the workflow engine sees it as a failed execution rather than a waiting task. This solution addresses all three focus areas systematically and should resolve your release delays.


This draft is based on general Teamcenter knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

I’ve seen this before. First thing to check is whether your workflow process is actually receiving the approval action. Go to Workflow Viewer and check the process instance status. Look at the task history to see if the approval action was recorded. Sometimes the action gets submitted but the handler doesn’t fire properly.

Custom EPM handlers can definitely cause this. If your handler was deployed last month and the issue started around that time, that’s your smoking gun. Check the Teamcenter server logs for any handler exceptions. Look specifically for EPMPerformSignoffHandler or any custom handler class names in the logs. Also verify that the handler is properly registered in the workflow template and that all required services are available when it executes.

Good catches. I checked the Workflow Viewer and the approval action IS being recorded, but the process isn’t advancing to the next stage. The handler registration looks correct in the template. I found some warnings in the server logs about notification service timeouts. Could the notification server status be affecting the workflow progression even if notifications aren’t critical to the approval logic?

“Confirmed this resolves the stall — clearing the backed-up notification queue via BMIDE and setting notification.server.timeout=30000 in tc_profilevars got our TC 12.3 approval workflow moving again.”

Absolutely. If your custom handler has any dependency on the notification service and it’s timing out, the handler execution fails and the workflow gets stuck. Check your notification server configuration in tc_profilevars. Look for notification.server.enabled and notification.server.timeout settings. Also verify that the notification queue isn’t backed up with failed messages.

I’d also recommend testing the escalation rules independently. The 48-hour timeout you mentioned might not be triggering because the workflow is in a failed state rather than a waiting state. Try creating a simple test workflow with just the manager approval stage and your custom handler. See if it reproduces. That will isolate whether it’s the handler, the escalation config, or something else in the workflow design.

Another thing to check: workflow assignments. If your custom handler modifies the assignee list or participant groups dynamically, make sure those operations complete successfully. I’ve seen workflows stall when a handler tries to assign to a group that doesn’t exist or a user that’s been deactivated.