Windchill part type definition - best practices

If you are referring to Soft Typing parts, I have some experience with it.  They are useful if you want to have different part types with different sets of attributes, initialization rules, icons, lifecycles, access right rules, version schemas and workflows. The kicker is that once created of a certain type, there is not "supported" way of changing the type. Not easily that is. So its up to the end user to get it right and right the first time. 

When we started using Windchill, we created soft types for parts and docs. We ran into maintenance issues like I illustrated above requiring lots of admin fixing.  Since then we reduced the use of soft types and used PartsLink to handle the various part types. Most of what we wanted was unique attribute sets. Since PartsLink allows for things to be classified at any point, easy to fix errors. Short answer, walk careful into this and if you can avoid the complexity, do so. 

I would create a entity-relation diagram as a start.
Which objects do you need?
Which attributes for every object?

Are there any special connections you need to consider?

We have a huge information model with 10+ different types and many attributes.

Some of it might be "nice to have" down the road, but our integration with other applications might also require extra types to be created.

Hi @MK_9853382,

I wanted to see if you got the help you needed.

If so, please mark the appropriate reply as the Accepted Solution. It will help other members who may have the same question.
Of course, if you have more to share on your issue, please pursue the conversation. 

Thanks,
Anurag

Probably not a best practise, but throwing it in out of curiosity whether someone points it out as something never to do...  😁

We have three part types used in hierarchical fashion. All have different set of attributes and the cogwheel-icons are of different color  😉

The topmost is a collecting object referencing basically only a project number, ie. not an actual 'part'. It's not going through approvals etc, basically just to make navigation (a lot!) easier for the folks not in engineering. Maybe folders for projects would be preferable instead, but the structure tree is pretty handy. 

Second level are products / sales items for the project. Approvals & revision rules apply as the project proceeds and EBOMs evolve. There can be several under a project.

Lowest level are your 'typical' WTPart EBOMs. Engineering has started to use these also as collecting objects for WTDocs...

Works for us in ETO business.