We’re experiencing merge conflicts when multiple engineers edit the same BOM structure simultaneously in our manufacturing collaboration workspace. The scenario: Engineer A modifies quantities on BOM lines while Engineer B adds new components to the same assembly. When they both try to save, we get conflict warnings and sometimes lose changes.
We’re using BOM Line Compare tool but it’s not catching all conflicts before they happen. The merge interface shows differences but doesn’t provide clear guidance on which version to keep. This has delayed our BOM releases by 2-3 days in the past month.
Our concurrent editing workflow needs improvement. How do others handle this? Are there configuration settings we’re missing that would better support parallel BOM modifications?
The BOM Line Compare and Merge tool has limitations when dealing with concurrent edits at the attribute level. It’s designed more for comparing different BOM configurations rather than real-time conflict resolution. You might want to explore using change management workflows instead - route BOM modifications through ECOs which naturally serialize changes and prevent simultaneous edits.
Another option is implementing pessimistic locking at the assembly level. When someone starts editing a BOM, lock the entire structure until they’re done. It’s restrictive but eliminates conflicts entirely.
Look into the collaboration objects feature in TC 12.3. You can create shared workspaces where changes are visible in near real-time to all participants. It’s not perfect but better than the standard checkout model for teams that need concurrent access.
Consider establishing a structured workflow that addresses all three critical aspects of your concurrent editing challenges.
Concurrent BOM Editing Framework:
Implement workspace partitioning where different engineering disciplines work on designated BOM sections. Define clear ownership boundaries - for example, mechanical engineers own structure while manufacturing engineers own process attributes. Use Teamcenter’s access control to enforce these boundaries. Enable the “Show Checked Out Objects” preference so team members can see what’s actively being modified.
Merge Conflict Resolution Process:
Configure BOM Line Compare with proper comparison criteria. Go to Preferences > BOM Line Compare and enable these options: Compare quantities, Compare occurrence notes, Compare positioning. Set up a three-way merge strategy: baseline version + Engineer A changes + Engineer B changes. When conflicts occur, establish a priority rule - structural changes typically take precedence over attribute changes. Document this in your procedures.
Create a conflict resolution checklist:
- Identify conflicting properties (quantity, position, attributes)
- Review business impact of each change
- Consult with both engineers if changes affect functionality
- Apply winning change and document reason in occurrence notes
- Notify losing party to reapply their changes if still valid
BOM Line Compare and Merge Tool Configuration:
The tool works best when configured for your specific use case. Set comparison scope to “Selected Items and Children” for focused analysis. Enable “Show Differences Only” to filter out noise. Use the merge preview feature before committing - this shows exactly what the final BOM will look like.
For better conflict prevention, implement these practices:
- Daily workspace synchronization mandatory before BOM edits
- Use event subscriptions to notify teams when assemblies are checked out
- Establish “BOM editing windows” where only one discipline modifies structures during designated time blocks
- Leverage change management for significant modifications - ECOs naturally serialize changes
Consider upgrading your revision rule strategy. Use a “Latest Working” rule that automatically pulls the most recent changes, reducing version mismatches. Enable optimistic locking for attributes while maintaining pessimistic locking for structure.
For your delayed releases, implement a pre-release validation step using BOM Compare reports. Generate comparison reports between working and released versions to catch discrepancies early. This adds one day to the process but prevents the 2-3 day delays you’re experiencing from post-conflict cleanup.