I’d like to start a discussion about versioning strategies in Aras 13.0, specifically around the differences between CAD data versioning and document management versioning. Our organization is struggling with inconsistencies in how these two systems track changes.
CAD files go through multiple iterations during design (A, B, C revisions), while our document management system uses a different versioning scheme (1.0, 1.1, 2.0). This creates confusion when trying to cross-reference which document version corresponds to which CAD revision. The workflow alignment between engineering changes and document updates is particularly problematic.
What are your experiences with managing these parallel versioning systems? Do you keep them synchronized, or do you maintain separate versioning strategies? How do you handle cross-referencing between CAD revisions and related documents?
We faced this exact challenge. Our approach was to establish a master versioning policy that applies to both CAD and documents. We use the same revision scheme (A, B, C) for both, but add a minor version field for document iterations between major CAD revisions. So a document might be revision B.3, meaning it’s the third iteration of the document associated with CAD revision B. This maintains alignment while allowing document flexibility.
The key is understanding that CAD versioning and document versioning serve different purposes. CAD versions represent design iterations with engineering significance. Document versions often represent content updates, translations, or format changes. Instead of trying to synchronize version numbers, focus on relationship management. Use Aras’s affected items functionality to link documents to specific CAD revisions. When a CAD revision occurs, the system can automatically identify which documents are affected and need review. The version numbers themselves don’t need to match as long as the relationships are clear and traceable.
I think trying to force identical versioning on CAD and documents is a mistake. They have different lifecycles and change frequencies. CAD revisions are formal, controlled events. Documents may need minor updates for corrections or clarifications without triggering a full revision. Better to maintain separate schemes but use strong relationship tracking. Every document should explicitly reference which CAD revision it supports. The cross-referencing is handled through metadata, not version number matching.
From a governance perspective, separate versioning schemes are actually preferable. CAD follows engineering change control processes with formal approval gates. Documents follow content management processes with different approval requirements. Forcing them to use identical versioning creates artificial dependencies. A document might need urgent correction while CAD is stable. Or CAD might need revision while documentation is still being developed. The cross-referencing strategies should rely on explicit relationship attributes - every document has a ‘applicable_to_cad_revision’ property that specifies which CAD version it supports. This is more flexible and maintainable than trying to keep version numbers in lockstep.
This is a great discussion that highlights a common PLM challenge. After implementing versioning strategies across multiple industries, here’s my perspective:
CAD vs Document Versioning:
These should NOT use identical versioning schemes, but they must be coordinated. CAD versioning represents engineering changes to physical design - these are high-impact events requiring formal change control. Document versioning represents information updates that may or may not reflect design changes. A document might be updated for clarity, translation, or regulatory compliance without any CAD changes.
Best practice: Use engineering revision scheme (A, B, C) for CAD and allow documents to have independent version numbers (1.0, 2.0) BUT with explicit linkage. Every document version must declare which CAD revision(s) it applies to via a relationship property.
Workflow Alignment:
The workflows should intersect at decision points, not run in parallel. When a CAD revision occurs via ECO, the workflow should:
- Identify all documents related to affected CAD items
- Create tasks for document owners to review and update if needed
- Allow document updates to proceed on their own timeline
- Require document approval before CAD release to production
This creates a gate without forcing version synchronization. Documents can be updated multiple times during a CAD revision cycle without creating new CAD versions.
Cross-Referencing Strategies:
Implement a ‘Supported Configurations’ relationship between documents and CAD items. This relationship should track:
- Which CAD item and revision the document applies to
- Date range of applicability
- Type of support (operating manual, specification, test procedure)
- Effectivity (which serial numbers or production lots)
This approach provides clear traceability without artificial version coupling. A document at version 3.2 might support CAD revision B, while another document at version 1.0 might also support CAD revision B. The version numbers tell you about the document’s evolution history, while the relationship tells you about applicability.
We’ve found that organizations struggling with versioning confusion are usually trying to encode too much information in the version number itself. Version numbers should be simple sequential identifiers. All the complex metadata - what changed, why, what it applies to - should be in properties and relationships, not embedded in version schemes.
We implemented a hybrid approach. Major versions stay synchronized between CAD and documents - when CAD goes to revision B, all related documents also move to revision B. But documents can have minor versions (B.1, B.2) for updates that don’t affect the CAD design. This required workflow alignment where document changes are classified as either ‘CAD-impacting’ or ‘editorial’. CAD-impacting changes trigger coordinated revision of both CAD and documents. Editorial changes only version the document. Works well for us.