Cost management workflow task stuck at approval step after cost rollup

PLM Windchill
, , , , , , , ,
1

Our cost management workflow gets stuck after the automated cost rollup calculation completes. The workflow task remains perpetually in ‘In Progress’ status at the approval step, and no assignee can complete it. The workflow template defines an approval activity that should be assigned to the Cost Controller role, but the task appears to be assigned to a system account or is missing a valid participant.

Workflow history shows:


Activity: Cost Approval
Status: In Progress
Assigned To: <empty>
Started: 2025-06-07 14:23:15

We can see the cost rollup completed successfully, and the calculated costs are correct. But the approval step configuration doesn’t seem to be resolving the participant correctly. I’ve tried manual task reassignment through the workflow administrator tools, but the option is grayed out. How do we fix stuck workflow tasks when the participant mapping fails?

system 2

Here’s the comprehensive solution for your stuck cost management workflow:

1. Workflow Participant Mapping Issue: The root cause is how your approval step resolves participants. When cost rollup completes, it triggers the workflow in a system context. If your workflow template uses dynamic role resolution like this:


Role: Cost Controller
Context: Organization of Cost Object

This fails because the system service running the rollup doesn’t have organizational context, so the role resolution returns empty.

Solution: Change your approval step participant configuration to use static group reference:

  • Open your cost workflow template in Workflow Template Administrator
  • Edit the ‘Cost Approval’ activity
  • Change participant assignment from ‘Role’ to ‘Group’
  • Select the ‘Cost_Controllers’ group directly instead of using role-based resolution
  • Save and publish the updated template

2. Approval Step Configuration Fix: For automated workflows, you need to ensure participant resolution happens correctly:

  • Avoid using context-dependent expressions like ‘creator.manager’ or ‘object.organization.role’
  • Use absolute group references: cn=Cost_Controllers,ou=Groups,dc=company,dc=com
  • Alternatively, use a workflow variable that’s set earlier in the process when user context is available

3. Manual Task Reassignment for Current Stuck Task: To fix the already-stuck task:

  • Log in as Windchill Administrator
  • Go to Site > Utilities > Workflow Administrator
  • Find your stuck workflow instance
  • Select the ‘Cost Approval’ activity
  • Click ‘Reassign’ and manually select users from the Cost_Controllers group
  • If reassign is still disabled, you may need to use the ‘Complete Activity’ option (requires admin privileges) and then restart the approval step

Alternatively, use the workflow command-line utility:


windchill wt.workflow.engine.WfEngineHelper -reassignActivity \
  -workflowId <workflow_oid> -activityId <activity_oid> \
  -newParticipant "cn=Cost_Controllers,ou=Groups,dc=company,dc=com"

Prevention for Future Workflows: The key is understanding that cost rollup is a scheduled background job running as a service account. Any workflow it triggers must use participant assignment methods that don’t depend on user session context. Static group references work reliably, while dynamic role resolution based on organizational hierarchy or object relationships often fails in automated contexts.

Update your workflow template to use static group assignment, republish it, and test by triggering a new cost rollup. The approval task should now be correctly assigned to all members of the Cost_Controllers group.

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.

3

The empty ‘Assigned To’ field is the smoking gun. Your approval step’s participant expression is probably returning null. This typically happens when the role or group specified doesn’t exist or has no members at the time the activity executes. Check your workflow template - is the Cost Controller role mapped to an actual group? Also, cost rollup processes sometimes run in a system context that doesn’t have access to the same organizational context as user-initiated workflows.

4

For manual task reassignment being grayed out, that’s usually a permission issue or the task is in a state that doesn’t allow reassignment. You might need to use the workflow administration utility to force-complete the stuck activity and then restart it. But that’s a workaround - the real fix is to ensure your participant mapping resolves correctly before the activity starts.

donna_815 5

Confirmed this resolves the stuck approval step — changing the Cost Controller role resolution from dynamic Organization context to a static principal fixed the empty participant list after cost rollup.

6

I checked the workflow template and the Cost Controller role is mapped to a group called ‘Cost_Controllers’ which definitely exists and has three members. Why would it return null if the group is valid? Is there something special about workflows triggered by automated processes like cost rollup versus user-initiated workflows? Could it be a timing issue where the rollup completes before the group membership is fully resolved?

7

Automated cost rollup processes often run under a system service account that doesn’t have the same organizational visibility as regular users. If your participant expression uses relative role resolution like ‘role:Cost Controller of object.organization’, it might fail because the system account doesn’t have an organization context. You may need to use absolute group references instead of role-based dynamic resolution for workflows triggered by background processes. Check if your workflow template uses dynamic participant expressions versus static group assignments.

8

I’ve dealt with this exact scenario. The issue is that cost rollup jobs execute in a different transaction context, and if the workflow activity tries to resolve participants based on the object’s current state or context, it can fail. The solution is usually to modify the approval step configuration to use a static group reference rather than a dynamic role resolution, or to ensure the cost object has proper organizational context before the rollup triggers the workflow.