Our auditors want to know if Implementer can restrict a developer from promoting their own work to production.

[blemay]

Our auditors are interested in separation of duties.  Both of the senior people in our shop can promote to production, but they would like to enforce a restriction that no developer could promote their own changes to production.  In other words, can we force Developer 1 to promote Developer 2's work, and vice versa?

We are currently on Implementer 10.2, but would upgrade if this is available in the current version.

[jsummers]

Absolutely we have our system setup on their user profile in Implementer to not allow promotion

with in the user profile  option 41

select the developer with option 15 Environment capabilities

Select the environment in question option 2 to change

Review settings but specifically the second page as shown above.

[blemay]

Well, yes, that would restrict someone from EVER promoting to that environment. 

But we have a small shop, and the point is that both senior people need to be ABLE to promote to production, but we would like to prevent them from promoting items that they checked out.  In other words, if Developer A checked out an object, then Developer B must promote it to production, and vice versa.  But both Developers must be able to promote to production.

This would insure that two sets of eyes had looked at the changes. 

On many projects this would mean that promotions to production would be doubled: if both senior developers worked on a project, then each would have to promote what the other developer worked on.  That is an acceptable trade-off for the benefit.

[jsummers · Accepted solution]

We use Integrity in conjunction with Implementer then you would have the ability to control who is making the change and in sure they are not implementing it.

With out Integrity I would have defer to Implementer support for that answer, sorry.