We have a custom change workflow where approval of a change notice should automatically update the release status of all affected items. The workflow completes successfully, but the release status on related parts and documents doesn’t propagate. I can see the change notice itself transitions to Released state, but linked objects remain in their previous status. Our workflow template includes standard handlers for status updates, and the status propagation rules appear correctly configured in preferences. The issue is intermittent - sometimes it works, sometimes it doesn’t. This is causing significant delays in our release process as we have to manually update each affected item. Has anyone experienced similar issues with status propagation in TC 12.3? I’m wondering if there’s something specific about how the workflow template should be configured or if we need custom handler logic to force the status update.
I’ve dealt with this issue multiple times in TC 12.3, and it typically comes down to three interconnected problems with status propagation rules, workflow template configuration, and custom handler logic.
First, verify your status propagation rules are correctly defined. The EPM_propagate_release_status preference needs to include all relevant object types, but that’s just the foundation. Check the EPM_status_propagation_depth preference as well - if your BOM structures are deep, you might be hitting depth limits. The default is usually 5 levels, which might not be sufficient for complex assemblies.
For workflow template configuration, the issue is often handler sequencing and context management. Your workflow needs to:
- Load all affected items into the workflow context (EPM-add-affected-items handler)
- Ensure all items are checked out if needed (EPM-checkout-items handler)
- Execute the status change (EPM-set-release-status handler)
- Propagate to related items (EPM-propagate-status handler)
- Check items back in (EPM-checkin-items handler)
The intermittent nature you’re experiencing is likely due to transaction timeouts with large change notices. When you have many affected items, the standard handlers can exceed transaction limits. You need custom handler logic to implement batch processing. Here’s the approach we used:
Create a custom handler that processes affected items in batches of 50-100 items. For each batch, explicitly set the status and commit the transaction before moving to the next batch. This prevents timeout issues and provides better error recovery. The handler should also implement retry logic for items that fail status update due to locks or permissions.
Another critical aspect is ensuring the workflow properly handles item states. If affected items are checked out by other users or have pending changes, status propagation will silently fail. Your custom handler needs to check item state before attempting status updates and either skip locked items or implement a queuing mechanism to retry later.
For TC 12.3 specifically, there’s a known limitation where status propagation doesn’t work correctly if the change notice workflow completes too quickly. Add a deliberate delay (5-10 seconds) in your workflow template after the approval task completes but before the status propagation handler executes. This gives the system time to fully commit the change notice status change before propagating to affected items.
Also review your workflow template’s error handling. If any single item fails status update, the entire propagation might roll back depending on your transaction configuration. Implement granular error handling that logs failures but continues processing remaining items.
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.
This sounds like a timing issue with the EPM handlers. The standard status update handlers might be executing before the relationship traversal completes. Check the handler sequence in your workflow template - you might need to add explicit wait conditions or reorder the handlers.
We had this exact problem. The issue was with our preference settings for status propagation. Check the EPM_propagate_release_status preference - it needs to be set correctly and the object types need to be listed. Also verify that your workflow template is using the correct EPM action handlers. In TC 12.3, there were some changes to how status propagation works with custom workflows. You might need to explicitly configure which object types should inherit status changes from the change notice.
I checked the EPM_propagate_release_status preference and it looks correct. The object types are listed properly. The intermittent nature is what’s puzzling me - it works for some change notices but not others. Could this be related to the number of affected items?
The intermittent behavior suggests transaction timeout issues. When you have many affected items, the status propagation might be timing out before completing. Check your method server logs during a failed propagation - you’ll likely see timeout warnings. You might need to increase transaction timeout values or implement batch processing for large change notices. Also verify that all affected items are actually loaded in the workflow context when the status handler executes.
Tested this on TC 12.3 and increasing EPM_status_propagation_depth from 5 to 10 resolved our missing status propagation on assemblies with six-plus BOM levels.
Another possibility is that your custom workflow isn’t properly invoking the propagation mechanism. The standard Complete handler should trigger status propagation, but if you’ve customized the workflow significantly, you might have bypassed that logic. Check if your workflow template includes the EPM-complete-task action with proper configuration. Sometimes custom workflows need explicit propagation handlers added.