Parallel Approver Paper Jan10

8/3/2019 Parallel Approver Paper Jan10

1/29

1

Configuring Parallel Approvers Notification

Using Oracle Approvals Management for

Oracle Self-Service Human Resources

(R11i10/R12)

An Oracle White Paper

November 2007


2/29

2

Table of Contents

1. Executive Summary ........................................................................... 31.1 Release Level..................................................................................................... 3

2. Introduction .......................................................................................... 3

3. References ............................................................................................. 34. Parallel Approval Process....................................................................... 3

5. Configuration for Parallel Approver Notification................... 45.1 Pre-requisites.................................................................................................... 4

5.2 Setup Steps........................................................................................................ 4

6. Real Time Execution....................................................................... 17

7. Limitations Known.......................................................................... 28

8. Conclusion.......................................................................................... 28


3/29

3

1. Executive Summary

The Approval process in an organization may make use of Approver groups where a group of people is

assigned to an Approver group. AME allows us to define approver groups as part of the approval process

and designate the group to approve a transaction approval. AME has the flexibility of allowing ParallelApprovers Notification. The approval notification in this case will be triggered for all the members in

parallel within an approver group. However, the availability of this feature in integrating products depends

on whether this feature is implemented/supported in those products. This white paper intends to provide a

configurable option within SSHR to handle Parallel Notification of approvers in an approver group.

1.1 Release Level

Important: This document is meant for HRMS 11.5.10 FP K Rup1 and forward.

2. Introduction

AME provides us the flexibility to define the approval processes based on an organizations requirements

without writing programming code. Business users can define the approval rules for the organization based

on the approval policies of their organization. If a business case requires approvers from a group of

approvers that does not exist as a chain of authority in an approver hierarchy supported by AME, then this

requires us to define an approver group containing the approvers. An Approver group must be assigned a

name, description, and members. The members must be ordered. The order number of the members

determines the order in which they are notified. The order numbers do not need to be unique. For example,

if we assign all of a groups members the order number one, the group will typically be notified in parallel.

3. References

Implementing Oracle Approvals Management

http://metalink.oracle.com/cgi-bin/cr/getfile_cr.cgi?282964

Implementing Oracle Self-Service Human Resources (SSHR) 4.2

http://metalink.oracle.com/cgi-bin/cr/getfile_cr.cgi?284440

4. Parallel Approval Process

Approver-group parallelization is controlled explicitly via the approver-group order numbers that a

transaction type assigns the approver groups. An approver group determines its members order numbers

using the groups Voting regime, and also the member order numbers assigned to static members or

generated for dynamic members. Dynamic members are assigned sequential member order numbers

according to the order in which the groups SQL query returns the members. Approver-group voting

regimes can have any of four values serial, consensus, first-responder-wins and order number. The
http://metalink.oracle.com/cgi-bin/cr/getfile_cr.cgi?282964http://metalink.oracle.com/cgi-bin/cr/getfile_cr.cgi?284440http://metalink.oracle.com/cgi-bin/cr/getfile_cr.cgi?284440http://metalink.oracle.com/cgi-bin/cr/getfile_cr.cgi?282964


4/29

4

values determine not only the order numbers of the group members, but also whether all group members or

one amongst them must approve the item.

The scope of this white paper is limited to the first-responder-wins voting regime only.

The first-responder-wins regime assigns group order number one to all members. All the members in the

group are notified. In this case, only the first responder must approve; all other members responses are

recorded but ignored.

5. Configuration for Parallel Approver Notification

SSHR can be configured to achieve the parallel notification of approvers within a group. This requires a

few set up steps, which are detailed below.

5.1 Pre-requisites

1. Access to CoreHR responsibility HRMS Manager responsibility2. Access to Approvals Management Business Analyst responsibility Approver Group set up

3. Availability of Position Control Roles Approver Type in AME setup

5.2 Setup Steps

1. Define Roles:

Using HRMS Manager responsibility define roles and assign the Person names to the roles who

are part of an approver group. For each approver group for which parallel notification is required,define a corresponding role in the Maintain Roles form with the same members assigned to the

role as in the approver group.

Navigation: US HRMS Manager responsibility Transaction Maintenance RolesMaintain

Roles Users

2. ApproverGroupset up:

Using Approvals Management Business Analyst responsibility within AME, select the

Transaction Type and define attributes/conditions as required for the business case. Define the

approver group with Voting regime first-responder-wins and add the Roles defined in Step 1 as

approver group members with Approver Type Position Control Roles. Add those roles to which

the corresponding group members were assigned whom we want to be the members of theapprover group. Give order number for the roles so that if we are using multiple roles/groups for

approval, the members of each of role will be notified based on the order number assigned to the

roles. Define Approval Rule with action type set to require approval from the approver groups.

Navigation: Approvals Management Business Analyst responsibility Business Analyst

Dashboard Select Transaction Type Define Attributes Conditions Define Approver

Groups Add Group Members (Roles) Define Rule


5/29

5

3. Availabilityof Position Control RolesApproverType in AME setup

While defining Approver group, the dropdown for Approver Type under Add Group Members

should have Position Control Roles. This is determined by the AME set up at the time of

implementation. Using Approvals Management Administrator responsibility, navigate to

Approver Types via the quick link on the right side of the page. Check if PQH_Role is present in

the list of Approver Types. If Yes, cancel from the page and navigate to Configuration variables

via quick link. The Allow All Approver Types variable should be set to Yes.

Important: This variable option cannot be reverted back to No once set to Yes.

Navigation: Approvals Management Administrator responsibility Admin Dashboard Quick

Links - Approver Types

Approvals Management Administrator responsibility Admin Dashboard Quick Links

Configuration Variables

Illustration

To illustrate the above setup steps, we will use the example of Change Hours function in

Manager Self Service.

Setting up Roles

We will define two roles Role 1 and Role 2 and assign two users Antony Cyril, Antony Zery

and Antony Samuel, Antony Metilda to each role respectively.

Antony Cyril & Antony Zeryare the members of the first approval group for which we require

parallel notification.

Similarly, Antony Samuel & Antony Metilda are the members of the second approval group for

which we require parallel notification.

Use the HRMS Manager responsibility to define roles.


6/29

6


7/29

7

Transaction Type


8/29

8

We will use the seeded AME Transaction Type for SSHR Oracle Self Service Human

Resources.

Use the Approvals Management Business Analyst responsibility to select the Transaction Type

from the Business Analyst Dashboard.

Click on Setup of the Transaction Type to define Attributes/Conditions/Action Types/Approver

Groups.

Alternatively, select the Transaction Type from the Approval Process Setup window on the right

side of Business Analyst Dashboard and go to Attributes/Conditions/Action Types/Approver

Groups/Rules as required.


9/29

9

OR

Defining Attribute

For this example we will use the existing attribute WORKFLOW_PROCESS_NAME. No action

needs to be performed in the Attribute window since we are using the seeded attribute.


10/29

10

Defining Conditions

We will use the condition WORKFLOW_PROCESS_NAME in

(HR_CHANGE_HOURS_JSP_PRC) where HR_CHANGE_HOURS_JSP_PRC is the seededSSHR function Change Hours.

Go to the Conditions tab to define the regular condition.

Click on Create to define a new condition

Search for the attribute WORKFLOW_PROCESS_NAME to define condition for the attribute.


11/29

11

Defining Approval Groups

Create two Approval Groups, Group 1 and Group 2 corresponding to the two roles defined earlier.

For Group 1, Add Approvers as Role 1 with order number 1 of Position Control Roles type

For Group 2, Add Approvers as Role 2 with order number 2 of Position Control Roles type

Use Voting Regime first-responder-wins for both the approver groups.

Go to Approver Groups tab to define the approver groups.

Click on Create to define a new Approver Group.

Group 1 with order number 1 and Voting Regime First Responder Wins


12/29

12

Click on Add Another Row under Group Members on the bottom of the Create New Approver

Group page

Add Role 1 as Approver of Approver Type Position Control Roles. The order number defaults to 1

Click Apply

Click on Create to add the next Approver Group


13/29

13

Group 2 with order number 2 and Voting Regime First Responder Wins

Add Role 2 as Approver of Approver Type Position Control Roles. The order number defaults to1.Click Apply

Defining Rules

Define a Rule with Action Type Require Approval from Group 1 and Require Approval from

Group 2.

Go to Rules Tab. Click on Create to define a new Rule using the Approver Groups defined above


14/29

14

Click on Next

Select the Condition defined earlier and click on Continue


15/29

15

Click on Next

Add Action of Require Approval from Group 1 of Action Type approval group chain of

authority

Click on Add Action to add the second approver group Group 2


16/29

16

The Group 2 is added. Click on Next

Click on Finish


17/29

17

6. Real Time Execution

1.Log in to the application and use Manager Self-Service responsibility

2. Navigate to Change Hours function


18/29

18

4. Select an Employee Jane John

5. Go to Action


19/29

19

6. Change the Work Hours and click Next

7. Make changes to Pay if required. In this example we are not changing the Pay. Click Next


20/29

20

8. Review the list of approvers generated by AME in the Change Hours: Review PageVerify the list displays Role 1 and Role 2 as the approvers

8. Submit the transaction

10. Log in as Antony Cyril and check the workflow notification


21/29

21

11. Verify the approval notification for the Change Hours of John, Jane is displayed


22/29

22

12. Do not approve the notification, logout without performing any action on the notification

13. Log in as Antony Zery and check the workflow notification



23/29

23

15. Parallel notification is achieved since both the members of the approver group received the

notification

16. Approve the notification in ZERYUSER (Antony, Zery) login

17. Login as Antony, Cyril and verify that the notification no longer displays in the Open

Notifications List. Verify the same for Antony Zery also


24/29

24

18. The notification displays in the All Notifications list for Antony Cyril and Antony Zery.

19. Click on the notification to view the Action History

20. Log in Antony Samuel and check the workflow notification


25/29

25


22. Do not approve the notification, logout without performing any action on the notification

23. Log in as Antony, Metilda and check the workflow notification



26/29

26

25. Parallel notification is achieved since both the members of the approver group received the

notification. The members of this group are notified after approval from the first group (role 1)

since the order number of this group is 2.

26. Approve the notification in Antony, Metildas login

27. Login as Antony, Samuel and verify that the notification no longer displays in the Open

Notifications List.


27/29

27

28. The notification displays in the All Notifications list as a closed notification for Antony,

Samuel and Antony, Metilda

29. Click on the notification to view the Action History

Note: If an approver in Role 2 rejects the notification, the rejection action appears in the action

history of the notification in All Notifications list for the other members in Role 1 and

Role 2 with a status of closed as shown below. There is no rejection notification sent to

the previous approver in the chain in this case. This is existing functionality and this

behaviour is not limited to this workaround.


28/29

28

7. Limitations Known

1. In the above example, if any member in group 2 performs return for correction, the return for

correction can only be done to that member in group 1 who acted upon it earlier. For the other

members of the two groups, the action history of the approval notification in All Notifications

list shows the return for correction action with a status of closed for the notification.

2. Similarly if a member in group 1 returns for correction, the other group members are not

notified of the return for correction. For the other members of group 1, their All Notifications

list shows the action history of the notification with Return for Correction action and with a

status of closed for the notification.

3. When approver is part of a role, the corresponding role-name would be appearing in the List of

approvers displayed in the Review page and in the notifications generated. The role-name to

which the approver belongs to replaces the actual approver name in the notifications and on the

review page. (Similar to how the role-names are displayed in the From column in the above

screenshot under #29.)

4. The Roles defined are static and cannot be made dynamic. If there are changes to the approversassigned to the roles, then the roles need to be manually updated to reflect the changes. For

example, if a role comprises of three approvers and if one of them is terminated, then the

terminated approver must be manually removed from the role.

5. The notifications generated by using this workaround will not be available under the function

All Actions Awaiting Your Attention where the notifications list is derived based on recipient

being login person user. When this workaround based on roles defined in Oracle HRMS is used,

it is recommended to access notifications from homepage worklist or using the workflow user

web applications responsibility

8. Conclusion

The process described in this whitepaper is a configurable workaround to achieve Parallel Notification of

Approvers within an approver group in SSHR. Though this feature is available in AME, the integrating

products may or may not support this feature.

Keeping in mind the limitations of this workaround, it is a fairly straightforward process to achieve parallel

notification within SSHR.

Disclaimer: Although various combinations of scenarios have been explored and tested within the scope of

this whitepaper, there may be some complex scenarios applicable specifically to your business, which you

are required to test.


29/29

Configuring Parallel Approver Notification Using AME for Oracle SSHR

November 2007

Author: Rosamma Sonia Varghese

Contributing Authors: Dheerendra Batra

Oracle Corporation

World Headquarters

500 Oracle Parkway

Redwood Shores, CA 94065

U.S.A.

Worldwide Inquiries:

Phone: +1.650.506.7000

Fax: +1.650.506.7200

oracle.com

Copyright 2007, Oracle. All rights reserved.

This document is provided for information purposes only and the

contents hereof are subject to change without notice.

This document is not warranted to be error-free, nor subject to any

other warranties or conditions, whether expressed orally or implied

in law, including implied warranties and condi tions of merchantability

or fitness for a particular purpose. We specifically disclaim any

liability with respect to this document and no contractual obligations

are formed either directly or indirectly by this document. This document

may not be reproduced or transmitted in any form or by any means,

electronic or mechanical, for any purpose, without our prior written permission.

Oracle, JD Edwards, and PeopleSoft, are registered trademarks of Oracle

Corporation and/or its affiliates. Other names may be trademarks

of their respective owners.

Documents

Parallel Approver Paper Jan10