Adding new Lifecycle state

[BenLoosli]

We have been running Windchill/PDMLink since V8 and are now on 10.0 preparing to move to 10.2.

One of the managers has asked what would be involved to add a new state to our Promotion Requests.

We currently have: Design, Draft, Prototype, Pre-Release, Release, Canceled and Under Review.

We would like to add a Development state between Draft and Prototype.

The Development state would be used for changes that did not require a Change Request review before implementing as the parts are being developed and changed as the design is tested. Once they design was finalized, it would then be promoted to Prototype for more formalized testing with other production equipment. When those tests are completed, it would then be promoted to Released.

My questions are:

1) What files need to be modified to add a new state?

2) What impact will adding a new state have on existing files?

3) Can the new state be isolated so it only shows on new files of a certain type (.prt, .asm)?

Ben

[bsindelar]

Ben,

1).  If the life cycle state already exists in Windchill OOTB, you do not need any additional files.  You simply select it when adding a new state to the life cycle template in the life cycle template administrator utility.  If the state does NOT exist, you can add it by using the enumcustomize utility and accessing the resource bundle wt.lifecycle.StateRB.  After adding the state you will need to rebuild the resource, shut down WC, run a makejar, then start WC back up in order for it to appear in the life cycle template administrator.

2.)  There is zero impact on existing objects within Windchill.  In fact, existing objects won't even take the new iteration of the template until the next revision of that object is created, which can either be desired or an issue based on your requirements.  There is a utility to mass update the life cycles of already-existing objects too (LCReassignUtility - you can find it in Windchill Help Center).

3.)  The state will show in Windchill as existing within its template on any objects that use the life cycle template(s) in which the state exists.  Through the life cycle template's definition and workflows surrounding the objects you can determine if the new state should or shouldn't ever be able to be "activated" life cycle state on the object.  This gets into the realm of business process consulting.

I hope this helps - I've done a lot of business process consulting around life cycle templates.  Feel free to bounce any other questions/thoughts on this topic off of me if desired.

[MikeLockwood]

Creating states / using states in lifecycle templates is well documented as Bob notes.

Just a comment to add though: You may want to think about the set of states applied to product data and to the Promotion Request.

The data might progress through Design, Draft, Prototype, Pre-Release, Release, Canceled and Under Review.

The Promotion Request normally progresses from Open to Under Review to either Approved or Rejected.  If you make a quick diagram and lay them next to each other it helps.  The product data is at some state after the last checkin, then the request is created and normally immediately goes to Under Review while people are approving it.  There is an option for the Product data to go to the "lock" state during this time (configured in the product data lifecycle, not the Promotion Request lifecycle).  On request approval, the product data goes to Released or similar and the request goes to approved.  On reject, the product data returns to it's original state and the request goes to rejected.  Again, simple diagrams help quite a lot.

Note: A change to the request lifecycle template is effective for new requests.  A change to the product data lifecycle is effective for new data and when existing data is revised.

[doehr]

Bob and Mike gave good responses, I just wanted to add some specific details. I had to do a mass upgrade recently where I added multiple new states to our entire part and document database.

From the sounds of it you want the Parts to have the new possible state Development. Only the WT parts will need this since they have the primary State of the part, not the CAD files and drawings. You'll need to follow these steps:

1. Add the Development state to the Part Lifecycle Template. If Development isn't in the list of available States for you, use the enumcustomize function from the Windchill shell as Bob mentioned
2. Run the LCReassignUtility function to update every current part in the system with the upgraded lifecycle template. Set the Organization into the contextID field in that utility properties file to hit the entire database at once.
3. Update all the additional details. Access rules in the Policy Administrator for who can do what to them at that state, Transitions, Set State robots in workflows...make sure everything that may use/be controlled by that state can handle it.

[LoriSood]

Hi Ben, was the above information helpful for you?