Skip to main content
L
lgrant16-Pearl
16-Pearl
October 21, 2025
Question

Maturity phase change without Revision.

  • October 21, 2025
  • 2 replies
  • 482 views

Wondering who has implemented this?

I did at one med device to allow pre-production CAD items to be promoted to Production when no data had changed if they provided appropriate supporting (validation) documents in the change.

 

Why:

Forcing a revision creates work that is not needed for the data authors and approvers.

We use the same rev scheme and we can watermark / stamp (cover page) to show the effectivity and state.

2 replies

Catalina
CatalinaCommunity Manager
Community Moderator
October 28, 2025

Hi @lgrant 

Thank you for your question. 

Your post appears well documented but has not yet received any response. I am replying to raise awareness. Hopefully, another community member will be able to help.

Also, feel free to add any additional information you think might be relevant. It sometimes helps to have screenshots to better understand what you are trying to do.

 

Best regards,

Catalina | PTC Community Moderator
joe_morton
18-Opal
joe_morton18-Opal
18-Opal
November 25, 2025

Yes, this is how we operate. For us, new objects start at revision A.1 with state Work In Progress. They iterate until ready, say A.15, then the user promotes to a released state for prototyping. A.15 is now in the state for Prototype. If there are no further changes to the design (just additional documents), revision A can go to Production. 

 

If a design change is needed at any point, the user starts a new revision and the design goes to B.1 with state Work In Progress again.

L
Ladric12-Amethyst
12-Amethyst
December 1, 2025

Hi @joe_morton 

Good to know. We are considering using a different Version series for just the State change.

Something like this:

In concept/development it would be 1.Iteration, 2.iteration (1.1 IN WORK, ... 1.5 Concept, 2. 1 IN WORK... 2.4 Development)

then the Version that would be promoted would have a number added to that Revision if it was not revised.

1.5 Concept would become 1.1.5 Development.

The second digit would only be used on that state change.

1.5 Concept -> 1.1.5 Development, A.1.1 Production

If 1.1.5 Development was revised it would be 2.1

When A.1.1 Production is revised it would be B.1 

 

In this way, there is what looks like an iteration in the History table with the new change listed above the previous change and a new date etc.

Since the Revision does not change, the associated objects that may reference that version would not need to be revised.

The only issue would be objects that change from numeric to alpha if the associated object had a table that named the Rev. Not all our objects start at numeric and move to alpha.

 

joe_morton
18-Opal
joe_morton18-Opal
18-Opal
December 1, 2025

Hi @Ladric

Thanks for the follow up. To be honest, I didn't really follow that completely. From the bit I did follow, I see a red flag I'd recommend you review before proceeding.

 

The normal Windchill versioning, as you know, is Revision.Iteration but there is at least 1 case where a 3rd indicator is used. You should be extremely careful adding a 3rd indicator and make sure it will be compatible with these cases (and possible more I'm not aware of):

 

  • Projects - These use a 3rd indicator. If you checkout A.1 from a Product/Library, it can be iterated within the Project as A.1.1, A.1.2, etc. When it is checked back in, it will become A.2 in the Product/Library. 
  • Manufacturing BOMs - I'm not as knowledgeable here, but there are cases where a 3rd indicator is used

In both of those cases, the 3rd indicator is a lower type of change than the iteration. I think your concept is problematic because in the example you gave, "1.5 Concept -> 1.1.5 Development" the new 1.1.5 would look like the 5th update to 1.1.

    Terms & ConditionsCookie settingsAccessibility statement