Hello @TDT
The OOTB "Basic" life cycle template makes use of only three states - "In Work", "Released" and "Canceled". It seems that this template has been designed in such a way that you have to use the "Set State" functionality to progress the object on the life cycle from "In Work" to "Released". I'm struggling to understand why PTC would deliver an OOTB life cycle template in this way if it is bad practice to change the state of objects using the "Set State" functionality. Have you got any resources you can share with me that details the circumstances surrounding when using the "Set State" action is bad practice?
I can understand why using the action could lead to misuse when users should be using an external process, such as a "Promotion Request", to trigger the state change of objects. However, there are some transitions between states in my life cycle that do not need to make use of any process more complex than the user simply deciding that they feel the object is mature enough to be moved onto the next state. With this in mind, I do not see any issue with giving them the ability to use the "Set State" action to progress objects when the object is at certain states. Would you agree?
Originally, State A was being used in my workflow to represent the state at which the object resides whilst it is being developed before moving to a "Released" state. State B was a state I was using to hide the object from all users apart from a small admin group. Users could move the object from State A to State B. As they would not be able to see the object when it was at "State B", it would appear deleted to them. However, it was only hidden from them in reality. I am using this approach so that users feel they can delete objects but the objects would actually always be recoverable. I would only want them to be able to move the objects to State B if they had never been "Released" before.
I think I have been over thinking this issue. To resolve this, I have introduced State C into my life cycle template. State C is the new state that objects first arrive at in Windchill. I have given users the ability to transition the object from State C to State B using the "Set State" action. The ability to transition objects to State B from State A is now prohibited. Once an object has been "Released", the life cycle template has been configured in such a way so that the object is never assigned back to State C. Instead, newer revisions of the object go to State A to be developed before being set to "Released" again. This has allowed me to only allow the transition to State B when the object on the template has not been set to "Released" before.
