Our change management workflow has a frustrating routing issue that’s delaying approvals by 2-3 days. After QA signs off on a change request (ECR workflow), instead of routing to the final approver (Engineering Manager), the workflow loops back to the originator for re-review.
The workflow routing configuration shows the correct path: Originator → Technical Review → QA Review → Engineering Manager → Complete. However, after QA approval, the task appears back in the originator’s inbox with status ‘Pending Revision’. We’ve checked the approval step mapping and all roles are assigned correctly.
What’s strange is that this only happens when QA adds comments during their approval. If QA approves without comments, the routing works fine and goes to Engineering Manager. We have custom exit conditions on the QA task that check for mandatory fields, but these shouldn’t trigger a loop-back. Any ideas what could cause this conditional routing behavior?
Another angle to consider: custom handlers on the ECR object itself. If you have an event handler that monitors change request property changes, adding comments might trigger a state change that conflicts with the workflow routing. The handler could be setting the ECR status to something that the workflow interprets as requiring originator review. Check your change request lifecycle state machine and any custom handlers registered on property change events.
I’ve identified your issue - it’s a classic misconfiguration in TC 12.4 change workflows involving comment handling. Let me break down the solution by addressing each focus area:
Workflow Routing Configuration:
Your routing path is correct at the template level, but TC 12.4 has a subtle change in how task outcomes are processed. When QA adds comments, the system creates a secondary workflow signal that can override the primary routing path. This happens because comments are stored as related objects (IBA attributes or workflow attachments), and their creation triggers a workflow re-evaluation.
The fix is to explicitly define comment handling in your routing rules. In your workflow template, add a routing rule that ignores comment-related property changes:
- Navigate to Workflow Designer > ECR Template > QA Review Task
- Add a routing condition: IF task.outcome = ‘Approved’ AND task.comments.exists() THEN route to Engineering Manager
- Set priority higher than any inherited routing rules
Custom Exit Conditions:
Your custom exit condition is being called twice - once when QA clicks approve, and again when the comment is saved (due to the property change event). The second invocation is where the problem occurs. The exit condition doesn’t find the expected state because the task is transitioning, so it returns a default ‘revision required’ result.
Modify your exit condition to be idempotent:
- Check task completion status before running validation
- If task.status = ‘Completed’, return the cached outcome (don’t re-evaluate)
- Store the first evaluation result in a task property: task.setProperty(‘exitConditionResult’, outcome)
- On subsequent calls, return the stored result
This prevents the exit condition from changing its mind after comments are added.
Approval Step Mapping:
The ‘Pending Revision’ status reveals the core issue. You have a custom approval step mapping that includes a revision path, and it’s being triggered incorrectly. In TC 12.4, approval step mappings support dynamic routing based on task metadata. Your mapping likely has:
- Approved (no comments) → Engineering Manager
- Approved (with comments) → Originator (for review)
This was probably intended to handle cases where QA requests changes, but it’s triggering on all comments, not just revision requests.
The Complete Fix:
-
Modify approval step mapping to distinguish between comment types:
- Add a task property: ‘revisionRequired’ (boolean)
- Update QA task UI to set this property only when actual revisions needed
- Change routing logic: IF revisionRequired = true THEN route to Originator ELSE route to Engineering Manager
-
Update custom exit condition:
- Add state check: if (task.isComplete()) return storedOutcome;
- Cache first evaluation: task.setProperty(‘initialOutcome’, outcome);
- Ignore property changes after completion
-
Fix workflow template inheritance:
- Override the inherited routing handler in your ECR template
- Explicitly define all routing paths (don’t rely on parent template defaults)
- Test with both comment scenarios
-
Add workflow debugging:
- Enable workflow trace logging: wt.workflow.engine.traceLevel=5
- Monitor routing decisions in workflow.log
- Look for duplicate task completion events
After implementing these changes, test thoroughly with QA comments. The workflow should proceed to Engineering Manager regardless of comment presence, unless the ‘revisionRequired’ flag is explicitly set. This maintains the intended functionality while fixing the unintended loop-back behavior.
There’s no default loop-back behavior for comments in TC 12.4 change workflows. However, I’ve seen similar issues with workflow template inheritance. If your ECR workflow inherits from a base template that has conditional routing based on task outcomes, the child workflow might be picking up unintended routing rules. Check the workflow template hierarchy and look for any inherited handlers that process task completion events. Also verify the QA task action handlers - specifically the ‘Complete’ action configuration.
Looking at your symptoms more carefully - the ‘Pending Revision’ status is the key clue. This isn’t a standard workflow status in the base ECR template, which means you have customization involved.
This sounds like a workflow handler issue rather than routing configuration. When QA adds comments, it likely triggers a property change event that your custom exit condition is interpreting as requiring revision. Check if your exit condition logic includes comment field validation - it might be returning a ‘revision required’ status when comments are present.
I think the issue is in your approval step mapping. TC 12.4 introduced a new feature where approval tasks can have multiple outcome paths based on task properties. If your QA task has an outcome mapping that checks for comment existence, it might route to a ‘Revision’ path instead of the ‘Approved’ path. Look at the task template properties - there should be an outcome mapping table that defines routing based on task completion data. This would explain why comments trigger different behavior.