While the PeopleSoft Delegation framework for HCM caters to most business requirements, there are certain limitations* that need to be considered during implementations, specifically with respect to Absence Management and Time and Labor. This post is an attempt to document someof the known limitations so that appropriate decisions can be made during implementations to handle these scenarios.
1. Inability for proxy to approve own transactions:
Assume that employee 'A' reports to manager 'B'.'B' is going on vacation for 10 days (ofcourse he is not working in consulting!!) and delegates her Absence and Time approval transactions to 'A'. Now,what happens if 'A' raises an absence request? As 'A' reports to 'B', the request should be routed to 'B' for approval, but 'B' in turn has delegated absence approvals to 'A'. But, PeopleSoft Absence Management/Time and Labor follows the principle that employees should not be able to approve their own transactions and thus, 'A' will not be able to approve the absence request that was raised. This is a common scenario, especially for personal assisstants who report to executives in organisations and is seen as one of the main limitations of the delegation framework during most of our implementations.
2. Delegation of a delegated transaction not possible:
Assume that manager 'A' has delegated her Absence Approval transactions to manager 'B'. Now, manager 'B' decides to go on vacation and intents to delegate her Absence Approvals to manager 'C'. This will not be possible in the PeopleSoft delegation framework as already 'A' has delegated Abence Approvals to 'B'. Thus, delegation of a delegated transaction is not possible in the PeopleSoft delegation framework.
3. Delegator loses control once a transaction has been delegated:
A common business requirement we have seen is that the person who delegates a transaction should be able to still approve the transaction if required. For example, assume that there are certain transactions that require the approval of HRBPs, but HRBPs have HRBP assisstants who help them with their transactional tasks and thus the HRBPs have delegated their approval transactions to their HRBP assisstants. This means that when a transaction is routed to the HRBP for approval, it will be re-routed to the HRBP assisstant as delegation has been setup. Now, assume that the HRBP is in discussions with a line manager and the line manager enquires about the status of a transaction he had raised and was pending with the HRBP. The line manager says that it is an urgent request and he would like the HRBP to approve the transaction immediately. With PeopleSoft delegation framework, the HRBP will not be able to approve this transaction because the HRBP has delegated it to the HRBP assisstant. In short, when a delegator delegates a transaction to a proxy, the delegator loses the ability to approve transactions for the period, delegation is active. It is tobe noted that through configuration, the delegator can view the status of these transactions and these transactions can also be configured to appear on the worklist of the delegator. But, no approval action can be taken up by the delegator.
4. Active delegations removed when delegator goes on LOA:
Assume that a manager has delegated certain transactions to another manager. The delegator now goes on a leave of absence (LOA). The delegations made by the delegator will become inaccessible to the proxy if the delegator goes on LOA. We have discussed this scenario in detail here.
5. Proxy will not be able to access delegated transactions if there is a change in userid:
This is a rare scenario, yet something we have seen with some past clients. Assume that manager 'A' has delegated her transactions to 'B'. Assume that the userid with which 'B' logs into PeopleSoft HCM changes after the delegation has been setup (for eg. the userid format for the customer is first letter of first name + last name. This could change when an employee gets married). Now, 'B' will not be able to access the delegations from 'A' with the new user id. This is because, delegations in PeopleSoft are recorded using userids and not employee ids, so if there is a change in the user id, that will affect delegation.
For more information on these limitations and how to handle them during implementations, reach out to us by mailing to partner@hroiconsulting.com.
*A limitation is only a deficiency in the functionality and not a bug. Thus, this post does not address known bugs with the Delegation framework. We believe that while bugs will be resolved by Oracle, limitations may not be addressed by the Oracle product team and thus requires special consideration during implementations.
1. Inability for proxy to approve own transactions:
Assume that employee 'A' reports to manager 'B'.'B' is going on vacation for 10 days (ofcourse he is not working in consulting!!) and delegates her Absence and Time approval transactions to 'A'. Now,what happens if 'A' raises an absence request? As 'A' reports to 'B', the request should be routed to 'B' for approval, but 'B' in turn has delegated absence approvals to 'A'. But, PeopleSoft Absence Management/Time and Labor follows the principle that employees should not be able to approve their own transactions and thus, 'A' will not be able to approve the absence request that was raised. This is a common scenario, especially for personal assisstants who report to executives in organisations and is seen as one of the main limitations of the delegation framework during most of our implementations.
2. Delegation of a delegated transaction not possible:
Assume that manager 'A' has delegated her Absence Approval transactions to manager 'B'. Now, manager 'B' decides to go on vacation and intents to delegate her Absence Approvals to manager 'C'. This will not be possible in the PeopleSoft delegation framework as already 'A' has delegated Abence Approvals to 'B'. Thus, delegation of a delegated transaction is not possible in the PeopleSoft delegation framework.
3. Delegator loses control once a transaction has been delegated:
A common business requirement we have seen is that the person who delegates a transaction should be able to still approve the transaction if required. For example, assume that there are certain transactions that require the approval of HRBPs, but HRBPs have HRBP assisstants who help them with their transactional tasks and thus the HRBPs have delegated their approval transactions to their HRBP assisstants. This means that when a transaction is routed to the HRBP for approval, it will be re-routed to the HRBP assisstant as delegation has been setup. Now, assume that the HRBP is in discussions with a line manager and the line manager enquires about the status of a transaction he had raised and was pending with the HRBP. The line manager says that it is an urgent request and he would like the HRBP to approve the transaction immediately. With PeopleSoft delegation framework, the HRBP will not be able to approve this transaction because the HRBP has delegated it to the HRBP assisstant. In short, when a delegator delegates a transaction to a proxy, the delegator loses the ability to approve transactions for the period, delegation is active. It is tobe noted that through configuration, the delegator can view the status of these transactions and these transactions can also be configured to appear on the worklist of the delegator. But, no approval action can be taken up by the delegator.
4. Active delegations removed when delegator goes on LOA:
Assume that a manager has delegated certain transactions to another manager. The delegator now goes on a leave of absence (LOA). The delegations made by the delegator will become inaccessible to the proxy if the delegator goes on LOA. We have discussed this scenario in detail here.
5. Proxy will not be able to access delegated transactions if there is a change in userid:
This is a rare scenario, yet something we have seen with some past clients. Assume that manager 'A' has delegated her transactions to 'B'. Assume that the userid with which 'B' logs into PeopleSoft HCM changes after the delegation has been setup (for eg. the userid format for the customer is first letter of first name + last name. This could change when an employee gets married). Now, 'B' will not be able to access the delegations from 'A' with the new user id. This is because, delegations in PeopleSoft are recorded using userids and not employee ids, so if there is a change in the user id, that will affect delegation.
For more information on these limitations and how to handle them during implementations, reach out to us by mailing to partner@hroiconsulting.com.
*A limitation is only a deficiency in the functionality and not a bug. Thus, this post does not address known bugs with the Delegation framework. We believe that while bugs will be resolved by Oracle, limitations may not be addressed by the Oracle product team and thus requires special consideration during implementations.
2 comments:
I have a question. Assuming we delegate by position ID, what happens if employee A delegates approval authority to employee B and then employee A is separated from the organization? Does the delegation end at that point or does it stay in effect since the position continues to exist even though it's vacant?
I have a question. Assuming we delegate by position ID, what happens if employee A delegates approval authority to employee B and then employee A is separated from the organization? Does the delegation end at that point or does it stay in effect since the position continues to exist even though it's vacant?
Post a Comment