Family table design strategy

[VictorMartinez]

Hello everyone,

I am Victor from Spain.

At our company we are thinking to start using family tables to manage our family assemblies. However, we are still reluctant in how Creo manage future instance modifications. As we are using a PLM to manage our documentation, we are worried about the fact that instance can be modified without not even opening the generic.

For example, having a generic assembly (ASM0001)saved with 2 different instances (ASM0001_INST1 and ASM0001_INST1) on the BBDD . It is possible that in the future a colleague could modify and save the ASM0001_INST1 not modifying the generic and making a discrepancy on our BBD.

With that exposed, our question is: Does exist a way to block or prevent instance modifications out of the generic?

Thanks for your support! 

[khimani_mohiki]

Hi Victor, my advice would be do not use Family tables for assemblies, it might seem like a great time saver now, but if you want to start using PLM to manage product configurations it will be very painful. We use WTParts and EBOMs and have to effectively manage configurations in family tables then manage it again in the WT part structure.

[Tdaugherty]

Hi, 

I will also recommend against using family tables for assemblies. It does get pretty complicated and difficult. Maybe take a look at this?

That said, there are some options to prevent changes from being made. One option would be to restrict write access to users when parts are in a specific lifecycle state. In our system (Windchill), we use family tables for parts pretty often. To prevent those parts from changing, we promote them to a state that normal users don't have access to change.

You could also set rules at the product or library level. This is how we manage our library in Windchill. Users are able to view and download files from a particular library but they can't change them.

Ty