Skip to main content
B
BenLoosli23-Emerald III
23-Emerald III
June 13, 2019
Solved

Context Templates

  • June 13, 2019
  • 1 reply
  • 1514 views

In establishing a new Windchill installation, I understand that modified OIR, Workflow and Lifecycles are need to conform to your company business practices. Do the context templates need to be company specific? I would still copy then from the site level to a new name at the org level so updates do not change what is being used in the future and use the org level templates for any product and library created,

 

On a higher level are the Context Templates. Do these also need to be modified before being used to create new products and libraries? If they do, what sort of additional information needs to be defined that these files cannot pick up from the system org or site level?

 

I have no products defined yet. When I open the Product tab and select Create New Product the template drop-down is blank with 2 choices: General Product or Product Design. Can I just create a product named UPF and use one of these OOTB templates? (After I copy them to a new name at the org level.)

 

Anyone will to offer some suggestions on which way to go?

 

Windchill 11.0 m030 CPS08

Best answer by mmeadows-3

Not sure I’m entirely following your questions. Maybe this will help?

Business configuration recommended practices is to never modify PTC’s OOTB content. Thus, the general procedure for context templates is to create a context, configure it as desired, and then save (and export) it as a company specific template.

We name them to be company specific to differentiate them from OOTB templates.  It doesn't matter what they are named as long as it is consistent.  We do this for other items too, like OIRs.  Typically we use the very basic naming pattern '<company> <template type>' (e.g. UPF Product Template).

I’ve never seen anyone use the Product Design template. It was provided by PTC as an example of what is possible. However, everyone starts with the General Product template and configures as needed.

We also go back and hide the OOTB templates once we have defined a company specific template. That keeps context creators from picking an unapproved template.  If we need to start another context from the OOTB template, we can quickly unhide it, create our context, and hide the OOTB template again.

There are a few ways to make template updates. The cleanest assumes there is a test system, create a new context using the current company template. Make the desired changes to that new context, and then export it as a template. Go back to production and update the company template with the exported template.

This is a personal preference, recommended practice. When possible, I like to move all application context permissions up to the org and clear them from the templates. The only domain policy difference between the OOTB general product and library templates is one defined permission ‘Product Manager’ and ‘Library Manager’. Otherwise, each context repeats over 100 access permissions. Moving product and library permissions up to the organization domain (/Default/PDM) greatly simplifies domain policy interrogation and future changes.  If dealing with projects, define those in the /Default/Project domain.

1 reply

M
mmeadows-316-PearlAnswer
16-Pearl
June 14, 2019

Not sure I’m entirely following your questions. Maybe this will help?

Business configuration recommended practices is to never modify PTC’s OOTB content. Thus, the general procedure for context templates is to create a context, configure it as desired, and then save (and export) it as a company specific template.

We name them to be company specific to differentiate them from OOTB templates.  It doesn't matter what they are named as long as it is consistent.  We do this for other items too, like OIRs.  Typically we use the very basic naming pattern '<company> <template type>' (e.g. UPF Product Template).

I’ve never seen anyone use the Product Design template. It was provided by PTC as an example of what is possible. However, everyone starts with the General Product template and configures as needed.

We also go back and hide the OOTB templates once we have defined a company specific template. That keeps context creators from picking an unapproved template.  If we need to start another context from the OOTB template, we can quickly unhide it, create our context, and hide the OOTB template again.

There are a few ways to make template updates. The cleanest assumes there is a test system, create a new context using the current company template. Make the desired changes to that new context, and then export it as a template. Go back to production and update the company template with the exported template.

This is a personal preference, recommended practice. When possible, I like to move all application context permissions up to the org and clear them from the templates. The only domain policy difference between the OOTB general product and library templates is one defined permission ‘Product Manager’ and ‘Library Manager’. Otherwise, each context repeats over 100 access permissions. Moving product and library permissions up to the organization domain (/Default/PDM) greatly simplifies domain policy interrogation and future changes.  If dealing with projects, define those in the /Default/Project domain.

    Terms & ConditionsAccessibility statement