Hi Oscar,

Logically that is a difficult requirement/concept for ZMF itself to handle.

Both the promote and demote functions will obviously have an effect on the content of the testing environment. In a simplistic model, the situation you describe could lead to a developer removing a component from the test environment whilst the QA team are 50% through execution of their test plan. This could, in turn, lead to confusion, at best, and potentially to completely invalidating all testing and causing production problems if other checks and controls are not also implemented alongside this. So, as you correctly state, the product is certainly working as designed in this area to ensure that a single team or group of users have control over the contents of the test environment.

However, if you definitely have this requirement, and if you also have other checks and controls in place to cover the potential problems covered above, have you looked at the HLLX routines as a possible way of implementing your requirements?

For example, you could

a) grant both QA and the developers UPDATE access to the promotion security entity

b) then allow or deny the promotion or demotion request based on the specific requirements that you would have implemented in one or more of the PRDM* HLLX points.

Obviously you would need to ensure all of your user interfaces are covered by the selected HLLX(s) but, in theory at least, this may give you what you need.

 I hope this helps and gives you something to work with.

Best regards,

Steve