Skip to main content
8-Gravel
July 22, 2026
Question

Default Design Choice Selection for Configurable Modules

  • July 22, 2026
  • 3 replies
  • 75 views

We are currently using PTC Windchill+ 13.0.2.12 and are working extensively with the Configurable Module functionality.

During the configuration process, we noticed that it would be beneficial for users entering configuration data to have the ability to define a default design choice for a design option, representing a standard or most common configuration.

By default design choice, I mean a design choice that is initially selected when the configuration is created, without requiring any prior user input. The user would still be able to modify the selection as needed.

This capability could provide several benefits:

  • Faster configuration entry for standard products.
  • Improved data quality and consistency.
  • Reduced verification effort, since users would only need to review and modify deviations from the standard configuration.
  • Improved user experience by clearly indicating the preferred or recommended initial selection.

For example:

Design Option: Color

Design Choices:

  • Blue
  • Yellow (Default)
  • Red

In this example, Yellow would be preselected when a new configuration is created, while still allowing the user to change the selection if necessary.

While it is possible to add an indicator to a Design Option or Design Choice to identify the preferred selection, that approach does not provide automatic selection behavior and can be difficult to maintain if the preferred default changes over time.

Has anyone implemented a workaround for this requirement using standard Windchill functionality, such as rules, Variant Specifications, or customizations?

Additionally, I am interested in learning whether other organizations have encountered a similar need and would find this capability valuable as a potential enhancement in a future Windchill release.

Thank you in advance for your feedback and suggestions.

3 replies

Catalina
Community Moderator
August 7, 2026

Hi ​@MB_14519500 
 
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. 

Thanks, 

Catalina | PTC Community Moderator
joe_morton
19-Tanzanite
August 24, 2026

We are just starting to explore Options and Variants. What you’re recommending makes sense to me. One thought that comes to mind as a potential workaround is to create a Variant Specification that represents your default selections, then do a Save As against that to generate the next Variant Specification. Afterward, I think you can reconfigure the new Variant Specification, update just the needed Options, then continue from there.

A drawback I can think of is that you could easily create duplicate Variant Specifications this way. 

Not sure if that helps or not. Either way, I think your idea would be a good enhancement!

8-Gravel
August 25, 2026

Hi ​@joe_morton ,

Thank you for your feedback!

I agree that using a Variant Specification could serve as a workaround, and it appears that it would still validate against existing variants, helping to avoid duplication.

However, this approach requires users to first create a Variant Specification. My stakeholders would prefer to begin from the overloaded BOM so they can directly see which components are impacted by their selections. While I plan to provide BOM reports to support this process, the system is still relatively new within our organization, making it difficult to push back on their desire for greater transparency and visibility into the resulting product structure.

Thank you again for your support and suggestions!