While the Promote Lock Reset Function could be good for some customers, and while I can see it's potential for keeping the test environments squeaky clean at package install time, it is not a one-size-fits-all feature.  Here at Truist, we are very mature in our Approval pipeline processing.  We integrated the ChangeMan package record workflow into the Change Request scheduling and implementation processing within ServiceNow.  The Promote Lock Reset Function is a feature that would pose a risk at Truist as programmers may tend to overuse the feature to get past the package / Change Request approval halt rather than fix the promotion failure before proceeding, which defeats the purpose of ensuring that the promotions that failed should be reviewed and fixed to ensure that the test environment is cleaned up in the expected manner at package installation or baseline time. 

In addition, we have controlled test environments that our Release Team promotes code to for the programmer for testing and the failures may possibly go undetected without the programmer knowing.  The Release Team would have to notify the programmer of the promotion failure, widening the gap for the risk of overlooking the failure.  Uncontrolled environments (e.g. unit testing) that are solely managed by the package owner is another risk, as the package owner typically doesn't get overly excited sometimes about fixing promotion failures in these lower environments and certainly the Promote Lock Reset function would be abused again.  To have a promotion failure in an uncontrolled lower environment stop a package approval is NOT an acceptable course of action for our shop at this time. 

We also have teammates that work for the job scheduling side that have another approval workflow for package records that run remote simulations on their schedule changes before they deploy their packages to prod, receiving a Return code of 08 on the promotion simulations, which sometimes could be acceptable.  The scheduler teammate reviews the error and could determine the RC08 is good and then  proceeds on with the package install/baseline.  The scheduling team deploys approximately 300 to 500 packages per month running 3 shifts, and in these cases, those packages will need a Promote Lock Reset performed, however if we take it away from all of programming like we planned to do with customized REXX code to just allow admins the function, then we have a team of schedulers that will need admin assistance round the clock.  Talk about hand holding! 

The problem with this feature is it has been delivered with this new release upgrade with no alternative to turn it off without a LOT of custom coding and time spent planning and integrating into ServiceNow, which we don't have time for on this upgrade budget.  Discussions have already cost us 2 weeks of brainstorming, planning, what-if scenarios on how to get around a process that we would rather have been delivered with an easy way to turn it off .  therefore we are submitting this idea as an enhancement to get a process/code to turn it off from Micro Focus (now OpenText).  There are so many reasons why this promote lock reset function should be a 'turn it on if you want it' or turn it off if you don't want it'.  Forcing every organization that gets this v8.3 new release upgrade to take on this promote lock reset feature when it does not fit well within current streamlined package approval processes is a major hurdle to overcome.