We implemented the Rework option in our promotion requests similar to the out of the box template in 10.2.
The rework options works great, as long as they don't need to change the collection.
A secondary problem we've found is that often the promoter will forget they have a promotion in rework, and will create a new promotion request.
So we end up with a brand new promotion and one that has rework data recorded.
This leads to queue failures when it's trying to lock an object that's already locked in Under Review.
My first instinct is to check for the objects being in Under Review. Though when the second promotion is started it's at an In Work state. You could only catch the failure on the original promotion with all the data.
We perform a check of objects checked out already. We also have a terminate path as part of the Rework task if they find a duplicate promotion or need to change the collection and just can't move forward with it. Though, right now I have to play watchdog over the WfPropagationQueue watching for any failures until I implement some sort of fix/prevention because the promoter gets no notification of a failure, and even if they did they might not know what the failure message means or what they need to do about it.
A second idea might be to look for any open Promotions against a Revision. Though that would require a bit more processing.
Ideally we would want to eliminate the duplicate promotion before it even gets started, terminate it after creation, or trigger some sort of flag to the promoter that there is an open promotion.
Do these make sense, anyone have any other ideas I'm missing?
The New Prom Req wizard will not let users past the object collection screen if any object on it does not have a promotion transition from the current state in it's current cycle template.
Maybe check the lifecycle and see if there are unwanted Promote transitions. If you use the optional (but very helpful and highly recommended) "lock" transition to a temporary state at which there is no Promote transition, this seems like it would prevent the situation described.
Note: It's unbelievable, but the new Lifecycle UI add the Promote checkmark from every state to every other state on the first save (there is some algorithm in there created 15+ years ago and no one at PTC ever went back and removed it). There are literally thousands of Windchill systems around the world that have lifecycle templates littered with extra Promotion transitions. Also, if you do change the lifecycle template, you have to take relatively extreme measures to apply the latest iteration of the lifecycle template to all objects that use it.
The problem is while the Promotion is in Rework, the objects go back to In Work, which is the original promotable state and unlocked. They are set that way so they can be fixed and the promotion can be re-triggered from Rework back to Under Review and the objects are set back to Under Review awaiting approvals.
A Rework state on the objects might prevent this issue, but that would mean adding the lifecycle state to all objects. I think we considered this in the past for validating when objects were truly being reworked during promotion or change process. We try to limit lifecycle states on docs/parts/models for ease of understanding, also updating lifecycles on all the objects may be a bit more than we want to undertake at the moment.
I fully agree that it should be prevented to add the same object revision as resulting to multiple Change or Promotion Notices.
It will just cause issues and from the business point of view it does not make sense.
Each object revision should be reviewed, approved and released by a dedicated task and published to downstream systems by the notice.
You could use an pre-store event listener to prevent this as long this is not available OOTB and controlled by a preference.
Oliver Droop its not that straight forward.
Promotion Request is not a revision level tool - it is made for State management at the iteration level and supports the ability to set states back and forth. Preventing it at the Revision level would prevent use cases such as Promote from Prototype in Work to Prototype Completed and the for the same revision promote from WIP to Review. or Promote (demote) back from Prototype Complete to Prototype in Work.
For Change there are again two use cases that are supported for using the same revision on a Change Notice in Resulting objects. The first is updating or adding Effectivity to a revision - eg additional Effectivity statements in multiple contexts (CN1 Effective in Assembly 1 on January 1, 2017-, CN2 adds Effectivity for Assembly 2 on January 17, 2017 - February 11, 2017). The second use case is that CN3 is used to Obsolete the part, whereas CN1 was used to release it.
I could see two things in the future - a) a preference for sites that do not have these use cases or b) a business rule that checks if its on another Promotion Request or Change Notice and gives you feedback such that one could use it to either block or optionally allow
@JeffZemsky , apologies for posting on an old topic, but I wonder whether there's been anything recent in PDMLink in the way of a business rule or preference to prevent raising a promotion request on object currently in the rework loop (and therefore in the WIP or DRAFT state)?. We are facing the same issue and I'm reluctant to going down a customisation route.
@l4urence There is nothing that would prevent it today. However best practice would be for the rework loop to be something different than the normal WIP state -eg .REWORK. In this case it becomes clearer that the object is part of a Promotion.
Additionally it would be pretty easy to add a workflow check to see if the object is on another promotion and route the Promotion back to the user to edit before proceeding.
Thanks Jeff - that's pretty much what I've done but the users are effectively reworking the document at draft and then setting up a new promotion request rather than use the existing one. I think I need to review using draft for the change but use rework instead.
I had been into the same situation where users keep creating Promotion request on objects that are actually made available for Re-Work and is in "In Work" state.
And we actually solved it by writing a customized validator class which was hooked to our promotion request workflow which would check if the object has an existing promotion request and thereby blocks the action for a new Promotion request.
Amar Karthi ARASAN