Professional Documents
Culture Documents
1
Table of Contents
2
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 Parallel
Approvers 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.
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 organization’s 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 group’s 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
3
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.1 Pre-requisites
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.
4
3. Availability of ‘Position Control Roles’ Approver Type 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.
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 Zery are 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.
5
6
Transaction Type
7
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.
8
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.
9
Defining Conditions
10
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.
Group 1 with order number 1 and Voting Regime – First Responder Wins
11
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
12
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 to
1.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
13
Click on Next
14
Click on Next
Add Action of ‘Require Approval from Group 1’ of Action Type approval group – chain of
authority
15
The Group 2 is added. Click on Next
Click on Finish
16
6. Real Time Execution
1.Log in to the application and use Manager Self-Service responsibility
17
4. Select an Employee Jane John
5. Go to Action
18
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
19
8. Review the list of approvers generated by AME in the Change Hours: Review Page
Verify the list displays Role 1 and Role 2 as the approvers
20
11. Verify the approval notification for the Change Hours of John, Jane is displayed
21
12. Do not approve the notification, logout without performing any action on the notification
14. Verify the approval notification for the Change Hours of John, Jane is displayed
22
15. Parallel notification is achieved since both the members of the approver group received the
notification
23
18. The notification displays in the All Notifications list for Antony Cyril and Antony Zery.
24
21. Verify the approval notification for the Change Hours of John, Jane is displayed
22. Do not approve the notification, logout without performing any action on the notification
24. Verify the approval notification for the Change Hours of John, Jane is displayed
25
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.
27. Login as Antony, Samuel and verify that the notification no longer displays in the Open
Notifications List.
26
28. The notification displays in the All Notifications list as a closed notification for Antony,
Samuel and Antony, Metilda
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.
27
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 approvers
assigned 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.
28
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
29