It is generally not a good business practice to have the owner or initiator of a WF transaction to be able to approve it. There are may common sense examples, including the case when a user submits an expense report for business expenses and then that user is able to approve it. Such cases may not go well with the audit team. Hence, workflow implemented a fix that prevents the approver from reassigning the approval notification to the owner of the transaction or to the sender of the current notification. This fix came about in these patches:
However, depending on business needs it may be necessary to allow manual delegation or automatic delegation via vacation rule of a notification to the owner of a WF transaction or the sender of a current notification.
The former scenario (preventing delegation) would be more secure and provides a higher degree of legitimacy as there would be no way for the initiator to be involved in the approval process. Thus, the application of this scenario is quite obvious.
The latter scenario (allowing delegation) would allow flexibility in an approval process and a speedier run through it especially in the case of an unavailable approver as there would be no waiting on that approver to respond. A typical example of this scenario is in the case where the highest-level approver is unavailable due to vacation or any other reason. If that highest-level approver is not permitted to delegate to a subordinate while away, then how are requests going to get though and the business kept moving? Thus, the need to allow delegation to the next level down, which could either be the owner or the previous sender.
Therefore, in Oracle EBS 12.1.3+ and 12.2.4+ there are 1-off patches that give a WF Functional Administrator the ability to control delegation or reassignment of a notification to the owner or previous sender via a profile parameter.