We’re experiencing an unusual workflow behavior in our quality management process. After a manager approves a quality task (NCR closure), the workflow unexpectedly routes back to the originator instead of proceeding to the final closure step.
The workflow routing logic appears correct in the template definition, and the participant resolver is configured to identify the quality manager role. We’ve verified that conditional transitions are set up to move forward after manager approval, but something is causing the loop.
This is blocking our NCR closure process and creating confusion among team members who receive tasks they’ve already completed. Has anyone encountered similar routing issues with quality workflows in 11.1?
The issue is likely in how your conditional transitions are evaluating the approval state. Here’s what you need to verify systematically:
Workflow Routing Logic:
Examine the transition conditions leaving the manager approval activity. The expression should explicitly check for approval status (e.g., taskResult == ‘APPROVED’). If the condition is ambiguous or references the wrong variable, it may default to the originator path. Review the routing table in your workflow template to ensure the approval path has higher priority than any default routing.
Participant Resolver Configuration:
Verify that your participant resolver for the manager role is scoped correctly. Even though it’s returning the right user, check if there are multiple resolver rules that could conflict. Look at the resolver’s filter criteria - if it’s using team membership or organizational structure, ensure the originator isn’t inadvertently included through a secondary group membership. The resolver should have explicit exclusion logic for the task initiator.
Conditional Transitions:
This is where the problem most likely exists. Check these specific areas:
Verify the workflow variable capturing manager approval is correctly named and scoped throughout the process
Ensure the transition condition uses exact string matching (case-sensitive) for approval values
Look for any ‘else’ or default transitions that might catch the flow if the primary condition fails
Check if there’s a timeout or escalation path that’s being triggered inadvertently
In the workflow template editor, add logging expressions before and after the conditional transition to capture variable values. This will help you see exactly what’s being evaluated when the routing decision is made. Most often, this looping behavior occurs because the approval status variable is null or contains an unexpected value, causing the conditional logic to fail and route to a default path back to the originator.
Also check if your workflow has any custom Java-based routing expressions that might need debugging. The workflow process history should show you the exact path taken and any variable values at decision points.
This draft is based on general Windchill 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 behavior before. Check your workflow template for any ‘on rejection’ paths that might be misconfigured. Sometimes a conditional transition can evaluate incorrectly if the approval state isn’t properly captured in the workflow variable.
Tested this on Windchill 12.0 and fixing the taskResult variable reference in the conditional transition expression on the manager approval activity stopped the loop back to the originator.
We had something similar happen last year. In our case, the participant resolver was returning multiple users including the originator, which caused the workflow engine to route back. Double-check your role mapping configuration and make sure the originator is explicitly excluded from the manager approval pool. Also verify that your conditional transition expressions are using the correct workflow variables for approval status.
Thanks for the suggestions. I checked the rejection paths and they look fine. The participant resolver is definitely returning only the manager role, not the originator. Could this be related to how the workflow evaluates the completion status?
Look at your workflow process variables carefully. There might be a variable assignment issue where the approval status isn’t being set correctly after the manager completes their task. This can cause the conditional logic to fail and default to an unexpected path. Check the workflow history for the specific NCR instance to see what variable values exist at each step.
I’d recommend checking if there’s a custom participant resolver or routing logic that was added to this workflow. Sometimes customizations override the standard behavior in unexpected ways.