Approvals

Approvals Overview

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

the picture is described in the document text

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:

The dynamic approval workflow processes send notifications to approvers and notification recipients identified in the approver list.

Parallel Approval Process for Oracle SSHR Transactions

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.

See: Using the Parallel Approval Process in Oracle SSHR

Features of Approvals in SSHR

Does SSHR provide a secure approvals tool?

Yes. Oracle SSHR can use dynamic approvals with Oracle Approvals Management (AME) or with a PL/SQL package to provide a secure approvals environment.

Why does SSHR use both customizable PL/SQL packages and AME for approvals?

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.

What is the advantage of using Oracle Approvals Management?

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.

Can the approvals chain be configured to meet my requirements?

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.

Do I need a separate license to use Oracle Approvals Management?

No. Oracle Approvals Management is included if you purchase any application license.

Approvals

Approvals in SSHR

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.

See: Implementing Oracle Approvals Management (AME)

Oracle recommends that you use Oracle Approvals Management (AME) for all SSHR functions, however, all of the following alternatives are available:

Oracle Approvals Management (AME) Configuration

Oracle Approvals Management (AME) is a web-based application that is integrated with Oracle Workflow and enables you to define business rules to control your approvals processes.

With AME, you use the following components to define your approvals processes. They are associated with a transaction type for a particular application.

For more information on the components used in AME, see: Oracle Approvals Management Implementation Guide

Default Use of AME Configuration in SSHR

Oracle SSHR delivers an AME configuration that emulates functionality delivered in the PL/SQL package. This configuration delivers a supervisor-based approvals hierarchy using AME rules.

The default AME configuration consists of:

Standard AME Attributes for SSHR

Oracle SSHR provides the following AME attributes to help you define your approvals processes:

Attribute Description
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_TERMINATION_REASON_SS Termination reason
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_APPRAISAL_TYPE_SS Appraisal type
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.

Configuring SSHR Approval Levels in AME

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:

To define a different approval level for a specific workflow process:

To define a new approval level (if the delivered approvals do not meet your requirements):

  1. 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):

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

Further Approvals Options

Allow updates of pending transactions

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:

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.

Use the Maintain Roles window to associate a role with a role type.

Route actions to HR representative

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.

Defer Update After Approval

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:

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

Using the Parallel Approval Process in Oracle SSHR

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:

For more information about the parallel approval process in AME, refer to the Parallel Approval Process topic in the Oracle Approvals Management Implementation Guide.

How the Parallel Approval Process Works in Oracle SSHR

When a self-service transaction that uses the AME rule with 'First Responder Wins' voting regime is submitted for approval, Oracle SSHR:

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:

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.

Setting up the Parallel Approval Process for Oracle SSHR Transactions

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'.

Example: Setup Steps for the Parallel Approval Process

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:

  1. Define Approver Groups

    1. Navigate to the Approvals Management Business Analyst responsibility.

    2. Click the Setup icon for the predefined Oracle Self Service Human Resources transaction type.

    3. Click the Approver Groups tab.

    4. Click Create.

    5. Create two approval groups: Change Job Approval Group 1 and Change Job Approval Group 2.

    6. 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.

    7. Click Apply.

    8. Click the Conditions tab and click Create.

  2. Define Conditions

    This example uses the predefined WORKFLOW_PROCESS_NAME attribute and HR_CHANGE_JOB_ TERMS_SS function.

    1. Select Ordinary as the condition type.

    2. Select WORKFLOW_PROCESS_NAME as the attribute.

    3. Enter HR_CHANGE_JOB_ TERMS_SS in the string value field.

    4. Click Apply.

    5. Click the Rules tab.

  3. Define Rules

    1. Click Create to define a new rule using the approver groups created in the previous steps.

    2. Enter the rule name and select List Creation as the rule type.

    3. Click Next.

    4. Select the condition defined in the previous step (HR_CHANGE_JOB_ TERMS_SS) and click Continue.

    5. Click Next.

    6. Select approval-group chain of authority as the action type. Select Require Approval from Group 1 as the action and click Add Action.

    7. Select approval-group chain of authority as the action type. Select Require Approval from Group 2 as the action.

    8. 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.

Using the Parallel Approval Process in Other Oracle HRMS Suite of Products

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:

Sample Code for Modifying Approvals Using PL/SQL

If necessary, you can review the logic in the check_final_approver and get_next_approver functions and modify them as required. These functions are within the HR_APPROVAL_CUSTOM package.

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.

??-- -Check_final_approver 

function check_final_approver

           (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

    select  paf.person_id

    from    per_all_assignments_f paf

    start   with paf.person_id = p_person_id

      and     paf.primary_flag = 'Y'

      and     l_effective_date

      between paf.effective_start_date

      and     paf.effective_end_date

    connect by prior paf.supervisor_id = paf.person_id

      and     paf.primary_flag = 'Y'

      and     l_effective_date

      between paf.effective_start_date

      and     paf.effective_end_date;

--

  l_person_id per_people_f.person_id%type := null;

--

begin

  -- 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;

  end loop;

  if p_forward_to_person_id = l_person_id then

    return('Y');

  else

    return('N');

  end if;

exception

  when others then

       return('E');

--

end check_final_approver;
()

-    -Get_next_approver 

function get_next_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

    select  ppf.person_id

    from    per_all_assignments_f paf

           ,per_people_f      ppf

    where   paf.person_id             = l_in_person_id

    and     paf.primary_flag          = 'Y'

    and     l_effective_date

    between paf.effective_start_date

    and     paf.effective_end_date

    and     ppf.person_id             = paf.supervisor_id

    and     ppf.current_employee_flag = 'Y'

    and     l_effective_date

    between ppf.effective_start_date

    and     ppf.effective_end_date;

--

  l_out_person_id per_people_f.person_id%type default null;

--

begin

  -- [CUSTOMIZE]

  -- 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;

  end if;

  -- close the cursor

  close csr_pa;

  return(l_out_person_id);

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

Implementing Oracle Approvals Management (AME)

There are several settings that you must configure in AME before you can use the functionality in SSHR.

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:

If you subsequently need to add approvals to your process, you can simply use a different AME condition.

To set up AME for SSHR

  1. Use an appropriate AME responsibility to check that the value of the following variables is Yes:

    • AllowFYINotifications

    • AllowAllApproverTypes

      If the value for this variable is No, you cannot use the Position approver type.

  2. 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

  3. 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.

  1. Query your function.

  2. Navigate to the Form tabbed region.

  3. Add the following parameter information to the Parameters field for your function:

    • pAMETranType=SSHRMS

    • pAMEAppId=800

  4. 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)

  1. Log on to Oracle Approvals Management using the appropriate AME responsibility.

  2. Select the SSHRMS transaction type.

  3. Select the Conditions tab and click on the WORKFLOW_PROCESS_NAME condition.

  4. Choose the Add Text Value button and enter the name of your new workflow process as an attribute value.

  5. Save your work.

Technical Information

Workflow Processes

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:

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:

Note: If you do not use AME.A or above, the workflow processes are as follows:

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.

Configuring Approvals in the Workflow Builder

If you are not using Oracle Approvals Management (AME), you configure the predefined approvals processes in the Workflow Builder. You set up the approvals process using workflow attributes.

Note: Oracle recommends that you use AME for your approvals instead of the customizable PL/SQL packages.

To configure approvals in the Workflow Builder

  1. Open the workflow item type.

  2. Navigate to the process you want to modify and double click to open the workflow diagram.

  3. 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.

  4. 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.

    See: Updating Workflow Objects

  5. 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

  6. 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.

  7. Save your work.