When you define your SSHR functions, you can decide whether they require approval before they are submitted to the HR tables. You can define different approval requirements for different transactions and vary the approval requirements as required. For example, you can configure the workflow processes so that the Address part of Personal Information requires approval but the Phone Numbers part does not. Alternatively, you can vary the Approvals requirements by responsibility so that records changed by employees would need approval but records changed by managers would not.
All approvals mechanisms used in SSHR follow a basic approval loop. The logic checks whether the current approver is the final approver in the hierarchy. If the current approver is not the final approver, the application fetches the next approver who then receives the approval notification. The next approver can either reject the transaction, approve the transaction, reassign the transaction, or send the transaction for correction to anyone in the approvals chain. The approver may also be able to update the transaction, depending on the system configuration.
The Basic Approvals Loop
Within the approvals process, the application uses rules to generate a list of approvers for the SSHR transaction. The way in which the list is generated depends on the approvals mechanism you are using (see Approvals in SSHR).
The application uses dynamic approvals by default. The dynamic approvals functionality comprises:
A self-service user interface which enables the initiating manager to add additional approvers an notification recipients, display the approvers list, and limit the number of approval levels.
An application which generates the default approvers. The standard tool is Oracle Approvals Management (AME). Alternatively, you can use the customizable PL/SQL packages.
The dynamic approval workflow processes send notifications to approvers and notification recipients identified in the approver list.
To simultaneously notify multiple approvers of Oracle SSHR transactions, you can set up the parallel approval process. You use Oracle Approvals Management (AME) components to set up the parallel approval process.
Yes. Oracle SSHR can use dynamic approvals with Oracle Approvals Management (AME) or with a PL/SQL package to provide a secure approvals environment.
Up until SSHR 4.1, customizable PL/SQL packages were used to define approvals in SSHR. From SSHR 4.1, however, the delivered functions used Oracle Approvals Management (AME) as standard. You can choose to use dynamic approvals instead of AME by configuring your self-service functions accordingly, however, Oracle recommends that you use AME for all your approvals as other approval types may not be supported in future releases.
Oracle Approvals Management enables you to define business rules to control your approvals processes. You can define conditions, rules, and attributes to define an approvals process to meet the requirements of your enterprise. For example, you could create an approvals process in which approval from a particular user is only required if a salary raise is above a set amount. Alternatively, you could set up an approvals process for a particular business process.
Yes. You can configure your approvals processes to include specific approvers or managers. You can also specify that particular users should receive notification of the approval. If you are using Dynamic Approvals, you can still configure your processes using the Workflow Builder.
No. Oracle Approvals Management is included if you purchase any application license.
The Approvals interface for SSHR functions differs according to the type of approvals you have implemented. From release 4.1, SSHR uses Oracle Approvals Management (AME) to define and manage approval logic for all delivered SSHR functions. You can also use AME with all custom functions that use SSHR version 4 and above.
Oracle recommends that you use Oracle Approvals Management (AME) for all SSHR functions, however, all of the following alternatives are available:
Dynamic approvals with Oracle Approvals Management (AME)
This interface allows you to add approvers to the approvals chain and specify their position in the approvals chain. You can choose whether the approver receives a For Your Information (FYI) notification or whether the approver must approve or reject the transaction. In addition, you can choose the type of approver. You can add the following approver types to the approval chain:
Add a person, for example, John White.
Add a user, for example, JWHITE.
Add a position, for example, Senior Manager - Accounts.
Note: If you select a position, each person with that position has access to the notification. When the first person holding that position approves or rejects the notification, AME processes the notification by either forwarding the approved notification to the next person in the approval chain, or by returning the rejected notification to the initiator.
When you have selected an approver, you can specify their position in the approvals chain (the insertion point). You can:
Select an existing approver as the insertion point.
You insert the new approver either before or after an existing approver in the list.
Append the new approver to the list.
You add the new approver to the end of the approval list or specify whether the new approver is the First or Last Post Approver.
Note: You can also select an order number as the insertion point, for example, Order: 3. In this case, the new approver is always be third in the approvers list.
For more information on AME, see: Oracle Approvals Management Implementation Guide
Dynamic approvals without AME
This interface comprises the Approvals and Notification Recipient sections, however, the list-modification functionality is less comprehensive than that provided by AME. The manager initiating the SSHR transaction can add additional approvers to the approval chain and nominate additional notification recipients (reviewers). The application sends notifications to these persons on submission or on approval.
You can disable the insert approvers and add notification recipients functionality and use standard approvals by configuring the Review activity for the workflow process. Oracle does not recommend this approach.
See: Review and Confirm
In this case, no configuration options are available, and the approvers list is as defined by the PL/SQL code. You cannot add approvers to or remove approvers from the approvers list.
With AME, you use the following components to define your approvals processes. They are associated with a transaction type for a particular application.
Attribute - this is a business variable, for example, a salary amount, user ID, or workflow process name.
Condition - a condition compares an attribute value with a set of allowed attribute values. For example, a condition could look at a salary amount. If the salary is greater than a specified value, a particular approver list is created.
Approval type and approval specifications - these components define the type of approver list that is generated. For example, to generate a supervisor-based approver list with 5 levels, you use the 'supervisory level' approval type with the 'requires approval up to the first 5 approvers' approval specification.
Rules - a rule links the other components together by associating one or more conditions with the approval type and approval rule.
For more information on the components used in AME, see: Oracle Approvals Management Implementation Guide
The default AME configuration consists of:
a single AME transaction type 'SSHRMS' with
the following conditions:
the following rules:
SSHR rule for at most 10 Approvers in supervisor chain
Requires approvals to the top of the approval hierarchy or to 10 levels above the initiator, whichever comes first
SSHR Payroll Contact inclusion rule
Requires pre-approval from payroll contact if the transaction results in a mid-period pay change
|HR_TRANSACTION_CREATION_DATE_SS||Transaction creation date|
|HR_IS_ASSIGNMENT_CHANGE_SS||Includes change to assignment data|
|HR_IS_SUPERVISOR_CHANGE_SS||Includes supervisor change|
|HR_IS_TERMINATION_SS||Includes termination change|
|HR_IS_LEAVE_OF_ABSENCE_SS||Includes absence change|
|HR_LENGTH_OF_SERVICE_IN_YEARS_SS||Length of service (years)|
|HR_PROPOSED_JOB_ID_SS||ID of proposed job|
|HR_PROPOSED_POSITION_ID_SS||ID of proposed position|
|HR_PROPOSED_GRADE_ID_SS||ID of proposed grade|
|HR_PROPOSED_LOCATION_ID_SS||ID of proposed location|
|HR_PROPOSED_PAYROLL_ID_SS||ID of proposed payroll|
|HR_ASSIGNMENT_CHANGE_REASON_SS||Proposed assignment change reason|
|HR_ASSIGNMENT_CATEGORY_SS||ID of proposed assignment category|
|HR_SELECTED_PERSON_ID_SS||ID of selected person|
|HR_PAY_BASIS_ID_SS||ID of payroll basis|
|HR_SELECTED_PERSON_PROPOSED_SUP_ID_SS||ID of proposed supervisor|
|HR_IS_PERSON_BASIC_DETAILS_CHANGE_SS||Includes change to basic details|
|HR_IS_SELECTED_PERSON_ADDRESS_CHANGE_SS||Includes address change|
|HR_IS_SELECTED_PERSON_CONTACT_CHANGE_SS||Includes contact change|
|HR_IS_RELEASE_INFORMATION_SS||Includes change to release information|
|WORKFLOW_PROCESS_NAME||Workflow process name|
|CURRENT_ASSIGNMENT_ID||ID of current assignment|
|CURRENT_EFFECTIVE_DATE||Current effective date|
|HR_PROPOSED_SALARY_BASIS_SS||Proposed salary basis|
|HR_ABSENCE_TYPE_ID_SS||ID of absence type|
|HR_IS_MID_PAY_PERIOD_SS||Includes mid-period change to pay|
For more information on using attributes, see: Oracle Approvals Management Implementation Guide.
To meet your business needs, you may add additional rules, conditions, or attributes within the delivered SSHRMS transaction type, or you can define a custom transaction type.
For more information on configuring AME rules, conditions, and attributes, see: Oracle Approvals Management Implementation Guide
It is relatively easy to make minor changes to the delivered AME configuration and some examples are provided below.
To define a different approval level for all SSHR workflow processes:
For example, to specify two approval levels: The approval level is currently defined in the rule 'SSHR Rule for at most 10 approvers in Supervisor chain'. You would edit this default rule and change the approval level for the supervisory level approval type to 'requires approval up to the first two superiors at most'.
To define a different approval level for a specific workflow process:
First you create a new condition with the attribute WORKFLOW_PROCESS_NAME and enter the workflow processes which will have the different approval level as the attribute values.
Then you create a new rule, for example, '2 approvers in supervisor chain'.
Use the 'supervisory level' approval type with the 'requires approval up to the first two superiors at most' approval
Finally, attach your new condition to the rule.
To define a new approval level (if the delivered approvals do not meet your requirements):
You create a new approval (for example, 'requires approval up to the first 15 superiors at most') in the 'supervisory level' approval type.
To define a particular user as the final approver, or final authority (even if they are not the last person in the approval chain):
You create a List Modification Condition and specify a user, for example, a manager, as the final approver. You would add this list modification condition to your rules so that the approval chain would stop at this specified approver. Alternatively, you could create a new rule, add the approval type for final approver and add the WORKFLOW_PROCESS_NAME condition so that this final approver rule would apply to selected processes.
For more information on the configuration options offered by AME, see: Oracle Approvals Management Implementation Guide
For information about function parameters associated with AME, see Supplied Functions
For descriptions of function parameters, see Menu Function Parameter Descriptions
An approver can update an action themselves, or return an action for correction to any recipient on the approval chain. However, the ability to update depends on two configurations:
The system profile option HR: Allow Approver Updates to Self Service Actions must be set to Yes.
The recipient must have a workflow role that allows edits.
To update pending transactions, approvers must have a workflow role with the appropriate role type attached to allow them to edit actions. They can then update actions regardless of their position in the approval chain.
There are two supplied role types that control approvers' ability to update pending transactions: SSHR Update Allowed and SSHR Update Not Allowed. These role types should not be used in conjunction with each other; use whichever is simplest.
SSHR Update Allowed
If you associate a role with this role type, any approver with that role can update a pending transaction. No one else can perform updates on pending transactions.
SSHR Update Not Allowed
If you associate a role with this role type, all approvers with that role are prevented from updating pending transactions; all other approvers can update pending transactions.
Use the Maintain Roles window to associate a role with a role type.
You can route actions to an HR representative. The application sends the action to all persons having a role associated with the seeded HR Representative role type. Use the Maintain Roles window to associate a role with this role type.
The first HR representative to process the action does so on behalf of all HR. This is especially useful in situations where the application encounters a future-dated change to a person's record. See Future-Dated Actions in Managing Dates in SSHR.
By default, the save of the SSHR transaction to the database is deferred after the final approval. This is to prevent any delay between the final approver clicking the approve button and moving on to the next notification.
The transaction is saved automatically when the Workflow Background Process runs. The system administrator needs to schedule this process to run periodically as needed.
When you run the Workflow Background Process you need to set the following parameters:
Item Type = HR
Process Deferred = Yes
Process Timeout = No
Process Stuck = No
If you need to modify the default behavior so that transactions are saved immediately after final approval, set the system profile HR:Defer Update After Approval to No at User/Responsibility/Application/Site level.
See User Profiles, Oracle HRMS Configuring, Reporting, and System Administration Guide
Oracle SSHR provides the ability to route transactions simultaneously to multiple approvers using the parallel approval process. Use Oracle Approvals Management (AME) to set up approval groups for the parallel approval process in Oracle SSHR.
The AME features that Oracle SSHR supports in the parallel approval process are:
Approver group voting method must be defined as First Responder Wins. All members in the approver group receive the transaction notification. Oracle SSHR considers a transaction as approved if any approver from the approval group first approves the transaction. No further action is required from other group members.
Parallelization rule is applied only at member level in an approval chain or approval group.
For more information about the parallel approval process in AME, refer to the Parallel Approval Process topic in the Oracle Approvals Management Implementation Guide.
When a self-service transaction that uses the AME rule with 'First Responder Wins' voting regime is submitted for approval, Oracle SSHR:
Sends the approval request to all members in the approval group in parallel.
Enables any member of the approval group to approve, reject, or return the transaction for correction to the transaction initiator.
Considers a transaction as approved if any one of the approvers approves the transaction as the voting method used is first responder wins.
Returns the notification to the initiator if any one member of the group returns it for correction.
Saves changes to the database after the transaction is approved by any one member of the approval group.
Displays an Action History region in the approval notification of the transaction to enable all members in the approval groups to know the latest status of the transaction. The Action History region displays the name of the approver, the date when a member of the approval group acted on the transaction, and comments if any.
Note: The transaction action history information is available in all notifications regardless of whether parallel approval feature is implemented.
If there is more than one level of approval and multiple approval groups are setup for parallel approval, then a member of the next approval group can return the transaction for correction to a member of the previous approval group who approved the transaction. Oracle SSHR routes requests for information notifications either to the initiator of the transaction or to any member of the approval group depending on who submitted the transaction last. As the parallel approval process is based on the first responder wins method, if a request for additional information is pending at any level in the approval process, then another approver from the approval group can either approve or reject the transaction.
Delegating notifications during the parallel approval process
If an approver delegates a notification to:
Another approver in the same approval group, then any member of the approver group apart from the person who delegated the notification can approve or reject the transaction.
A member in another parallel approval group, then any of the approval group members in that group can delegate the notification to members of that group or other group. Member who receives the notification and other group members can act on the notification.
A member outside of the approval group, then that member or the person who delegated the notification or approver group members can act on the notification.
Note: If approvers use the Transfer Ownership option when reassigning notifications, then the transfer option works in the same way as delegate in case of parallel approvals.
To set up the parallel approval process for Oracle SSHR transactions, you must use Oracle Approvals Management (AME). You can use the standard Oracle Self Service Human Resources transaction type for the parallel approval process. Otherwise, if you require additional conditions, rules, or attributes, you can create them using the supplied components as examples. For more information about Oracle Approvals Management, refer to the Oracle Approvals Management Implementation Guide.
When you set up the parallel approval process, you must ensure that approval group voting method is 'First Responder Wins'.
The following example assumes that you use the predefined components delivered with Oracle SSHR and Oracle Approvals Management (AME). You can set up the parallel approval process for any of the Oracle SSHR transactions.
This example explains how to set up the parallel process for the Change Job and Terms (HR_CHANGE_JOB_ TERMS_SS) transactions in the Vision Corporation business group. In this requirement, approvals are required from two approval groups: Change Job Approval Group 1 and Change Job Approval Group 2.
Complete the following steps to define the parallel approval process for the Change Job and Terms transactions:
Define Approver Groups
Navigate to the Approvals Management Business Analyst responsibility.
Click the Setup icon for the predefined Oracle Self Service Human Resources transaction type.
Click the Approver Groups tab.
Create two approval groups: Change Job Approval Group 1 and Change Job Approval Group 2.
Enter the name and description of the approver groups. Select First Responder Wins as the voting regime. Select Static as the usage type. Select the group members. Select required approvers and HR People as the approver type.
Note: You can select Dynamic as usage and write your own queries to retrieve approvers. For more information, refer to the Oracle Approvals Management Implementation Guide
For group 1, enter the order number as 1 and group 2, enter the order number as 2.
Click the Conditions tab and click Create.
This example uses the predefined WORKFLOW_PROCESS_NAME attribute and HR_CHANGE_JOB_ TERMS_SS function.
Select Ordinary as the condition type.
Select WORKFLOW_PROCESS_NAME as the attribute.
Enter HR_CHANGE_JOB_ TERMS_SS in the string value field.
Click the Rules tab.
Click Create to define a new rule using the approver groups created in the previous steps.
Enter the rule name and select List Creation as the rule type.
Select the condition defined in the previous step (HR_CHANGE_JOB_ TERMS_SS) and click Continue.
Select approval-group chain of authority as the action type. Select Require Approval from Group 1 as the action and click Add Action.
Select approval-group chain of authority as the action type. Select Require Approval from Group 2 as the action.
Click Next and then Finish.
When you complete this setup, Oracle SSHR displays a list of parallel approvers in the Change Job: Review page and routes the change job transactions based on the conditions and rules set up for the function.
You can configure the parallel approval process in other HRMS products that use the supplied Oracle Self Service Human Resources transaction type or a transaction type that is configured using the supplied type. For example, you can set up the parallel approval process for the following features:
Standard appraisals in Oracle Performance Management
Learner enrollments in Oracle Learning Management
Vacancies in Oracle iRecruitment
Make sure that your returned values are of the correct data type.
The following code shows the logic for the approval functions. If required, you can customize the code to use different approvals routings or to stop at a different grade level.
(p_forward_to_person_id in per_people_f.person_id%type
,p_person_id in per_people_f.person_id%type)
return varchar2 is
cursor csr_pa(l_effective_date in date) is
from per_all_assignments_f paf
start with paf.person_id = p_person_id
and paf.primary_flag = 'Y'
connect by prior paf.supervisor_id = paf.person_id
and paf.primary_flag = 'Y'
l_person_id per_people_f.person_id%type := null;
-- loop through each row. the rows are returned in an order which makes
-- the last row selected the top most node of the chain.
for csr in csr_pa(trunc(sysdate)) loop
-- set the l_person_id variable to the row fetched
l_person_id := csr.person_id;
if p_forward_to_person_id = l_person_id then
when others then
end check_final_approver; ()
(p_person_id in per_people_f.person_id%type)
return per_people_f.person_id%type is
cursor csr_pa(l_effective_date in date
,l_in_person_id in per_people_f.person_id%type) is
from per_all_assignments_f paf
where paf.person_id = l_in_person_id
and paf.primary_flag = 'Y'
and ppf.person_id = paf.supervisor_id
and ppf.current_employee_flag = 'Y'
l_out_person_id per_people_f.person_id%type default null;
-- open the candidate select cursor
open csr_pa(trunc(sysdate), p_person_id);
-- fetch the candidate details
fetch csr_pa into l_out_person_id;
if csr_pa%notfound then
-- if the cursor does not return a row then we must set the out
-- parameter to null
l_out_person_id := null;
-- close the cursor
end get_next_approver; ()
For more information on using PL/SQL, see Overview of Using PL/SQL in Applications, Oracle E-Business Suite Developer's Guide
Also, any custom functions you created prior to release 4.1 will use the customizable PL/SQL package as the default approvals mechanism. However, you can modify any custom SSHR functions to point to AME by adding two new function parameters.
Note: The AME rules and conditions always override any other workflow attribute settings that apply to approvals, for example, the attribute settings for the Review activity. If the Approvals Required workflow attribute is set to Yes for a workflow process but AME does not return any approvers, the process completes without requiring approval. As a general set-up recommendation, you should set up processes that currently do not require approval as follows:
Set the Approvals Required workflow attribute to Yes
Configure AME so that no approvers are returned
If you subsequently need to add approvals to your process, you can simply use a different AME condition.
To set up AME for SSHR
Use an appropriate AME responsibility to check that the value of the following variables is Yes:
If the value for this variable is No, you cannot use the Position approver type.
Use the Workflow Builder to set the Timeout value for the Notification activity in your workflow processes.
See: To Define Nodes in a Process, Oracle Workflow Developer's Guide
See: Timeout Transitions, Oracle Workflow Developer's Guide
If you have created custom workflow processes, use the Workflow Builder to replace the existing notification processes with the new process Notification Process for Approvers and Notifiers.
See: Diagramming a Process, Oracle Workflow Developer's Guide
To link a custom function to AME
You define additional function parameters in the Form Functions window. You should also check the workflow attributes for your workflow process using the Workflow Builder.
Query your function.
Navigate to the Form tabbed region.
Add the following parameter information to the Parameters field for your function:
Save your work.
To add a custom workflow process to the list of values for the condition attribute for the SSHRMS AME transaction type (required if using the delivered SSHR transaction type)
Log on to Oracle Approvals Management using the appropriate AME responsibility.
Select the SSHRMS transaction type.
Select the Conditions tab and click on the WORKFLOW_PROCESS_NAME condition.
Choose the Add Text Value button and enter the name of your new workflow process as an attribute value.
Save your work.
Notification Process for Approvers and Notifiers, which includes the following subprocesses:
FYI Notification Process (HR_FYI_NOTIFICATION_PRC)
Approvers Notification Process (HR_APPROVAL_NTF_PRC)
RFC Notification Process (HR_RFC_NTF_PRC)
Avoid Errors When Routing Approvals in Oracle SSHR
Currently, workflow transactions that use the Notification Process for Approvers and Notifiers SSHR approval process end in errors for the following reasons and users cannot track such transactions:
When an approver does not approve a transaction within the time period, the workflow updates the corresponding Oracle Approval Management (AME) transaction type with the No Response status. Then, the workflow tries to route the notification to the approver's supervisor based on the approval chain. If the supervisor is not available, then the workflow displays an error.
If the AME transaction type is incorrectly setup, then the workflow cannot route transaction for approvals. This happens because the workflow uses the list of recipients defined in the transaction type.
Using AME, you can define the adminApprover configuration variable for a transaction type. The adminApprover variable identifies the person or user account that AME identifies as the administrator who can correct the hierarchy issue so that transactions get processed without any errors.
Oracle SSHR notifies the administrative approver identified by AME indicating that an exception has occurred for transactions that use the SSHR approval process Notification process for approvers and notifiers.
The administrative approver receives notifications:
When a user submits the transaction on the Review page, even after receiving the Oracle Approval Management (AME) transaction type incorrect setup error.
When the approval chain is broken and workflow cannot route the transaction to the next approver. For example, the workflow routes transactions from employee A to employee B, and then from B to employee C. Once the approval process starts, C resigns from the enterprise. When employee B approves the transaction, the workflow process sends a notification alerting the administrator about the break in the approval chain.
When an approver does not approve a transaction within the time period, and if a supervisor is not available for the workflow to route the transaction.
Note: If you do not use AME.A or above, the workflow processes are as follows:
Approvals Process with Correction V5.0 (for dynamic approvals)
Approvals Process (for standard approvals)
Configurable Workflow Attributes
|Process Name||Function Name||Attribute Name||Description|
|FYI Notification Process||Notify||Message Name||Specifies the name of the message for the notification. You can create separate messages for notifications sent on submission of the transaction and on approval, for example.|
|FYI Notification Process||Notify||Expand Roles||To assign this notification to a role consisting of multiple users and to send an individual copy of this notification to each user in the role, select Yes. If you select No, only one copy of the notification is delivered to the role as a whole.|
|FYI Notification Proces||Notify||Performer||The role to whom the notification is sent. You can select a constant role name or an item type attribute that dynamically determines the role at runtime.|
Configurable Profile Options
For information on profile options to control whether users can update pending transactions, see: Further Approvals Options.
Note: Oracle recommends that you use AME for your approvals instead of the customizable PL/SQL packages.
To configure approvals in the Workflow Builder
Open the workflow item type.
Navigate to the process you want to modify and double click to open the workflow diagram.
Open the Review Page activity for your workflow process.
Note: You may have to drill down through several subprocesses until you reach the correct Review Page activity.
Make a copy of the process and any affected subprocesses. For example, if you are modifying the approvals for the Process Personal Information process, you would have to copy the Process Personal Information process, and the related subprocesses, for example, the Process Basic Details subprocess.
Select the Review Page activity for your process/subprocess and set the Approval Required workflow attribute (HR_APPROVAL_REQ_FLAG) to YES. This activates approval for your process/subprocess.
Note: The default value varies for different modules.
See: Review and Confirm
Decide how a process should pass through the entire approval chain, in other words, how many levels of approval are required. Set the approval level using the Approval Level attribute (HR_DYNAMIC_APPROVAL_LEVEL). Add an approval level value to the Default Value field. A value of 1 for example will pass the approval one level up the supervisor chain.
Note: The default number of level is 0, meaning that the number of levels is unlimited.
Save your work.