Enforce Criteria to Permit Life Cycle State Change

[Turko]

Version: Windchill 13.0

Use Case: I want to be able to only allow a transition from state A to state B in my life cycle if the object using the life cycle has not been set to "Released" before.

Description:

Has anybody got thoughts on the best way to approach this? I was thinking about introducing some custom JavaScript on the server to identify an attribute that would allow the code to detect if the object had previously been released before either permitting the transition or throwing an exception. Or, introducing code into the workflow. 

[TDT]

Hi @Turko ,

The requirement is to allow the object to transition from State A to State B only if it has never been released at any point in its lifecycle history.
At which stage of the process should this validation be implemented?

[Turko]

Hello @TDT 

Thanks for responding. I'm not quite sure how to answer that. Users should be able to manually set the state of the object from State A to State B when it has not been released before. However, the transition should not be possible when it has been released before. Does that help answer the question at all?

[TDT]

Hi @Turko,

An object is generally expected to progress through its defined process states.
In that case, why would users need the Set State action?
Typically, the Set State action is intended for administrators or a limited set of key users, primarily for exceptional or corrective scenarios rather than normal process flow.

[Turko]

I am making use of a basic life cycle which does not make use of any workflow. Consequently, users make use of the "Set State" functionality to progress the object to different states included on the life cycle.

You say that "Set State action is intended for administrators or a limited set of key users, primarily for exceptional or corrective scenarios rather than normal process flow." - is this something that is recommended by PTC?

[TDT]

Hi @Turko,

It is considered best practice to move an object through its lifecycle states via the defined process. Using the Set State action may lead to potential misuse.

From your use case, it appears that the object transitions from State A to State B during the initial release.

However, when the object is revised, it typically should not revert to State A. Could you please confirm if this is the expected behavior?

It would be more appropriate to use a Promotion Request to move the object from State A to State B, as this aligns with standard lifecycle and release management practices.

[Turko · Accepted solution]

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.

[TDT]

Hi @Turko,

I believe it is always best practice to move objects through the defined process, as this ensures that appropriate approvals and reviews are in place.

Relying on the process helps avoid situations where users may assume all required work is complete, while in reality certain validations or reviews may be still be pending from the user.

However, if you do not foresee any risks or issues with using the Set State action, then it may be acceptable in your specific scenario.

[Turko]

I totally understand where you are coming from. Workflows that are associated with life cycles can certainly ensure correct approvals are received and review processes are enforced. But I do think I have only given users the ability to make use of the "Set State" actions whereby I have no requirement to enforce any review/approval process before allowing the state change of the object. Thank you for your opinion and explanations on this subject - your input is valued! 😊