APPROVAL MANAGEMENT

OVERVIEW OF WORKFLOW & BPM

WORKFLOWS (APPROVALS & NOTIFICATIONS)
Workflow is a process in which tasks are routed automatically among
users for their consideration or action. The tasks are routed in a
defined sequence to achieve a defined result.

Recruiter
Hire an employee

First level Notification

Approver to Recruiter

Line Manager Payroll Manager

Second level Third level

Approver Approver
Second Level
Manager
WORKFLOWS (APPROVALS & NOTIFICATIONS)
HCM APPROVAL MANAGEMENT
APPROVAL POLICIES
PREDEFINED APPROVAL WORKFLOW
PREDEFINED APPROVAL WORKFLOW
(EXPLAINED)
APPROVAL TRANSACTIONS
APPROVAL TRANSACTIONS (CONT…)
APPROVAL TRANSACTIONS (CONT…)
APPROVAL RULES - OVERVIEW
UNDERSTANDING APPROVAL RULES
APPROVAL RULE
APPROVAL RULE – THEN STATEMENTS
APPROVAL RULE – THEN STATEMENTS
APPROVAL RULE – CREATION
APPROVAL RULE – CONFIGURING IF CONDITION
APPROVAL RULE – ADDING RULE CONDITIONS
APPROVAL ATTRIBUTES
COMBINING MULTIPLE RULE CONDITIONS
CONDITIONS DETAILS: VIEWS
ADDING APPROVERS
CONFIGURE APPROVER SETTINGS
CONFIGURE APPROVER SETTINGS – ACTION
TYPE
APPROVER TYPES

Dynamic
Approvals

Job Level – Job level manager hierarchy

APPROVER TYPES
MANAGEMENT HIERARCHY
APPROVAL RULE – LEVEL 2

Approval rule:
Employee
2 levels start with employee
Susan Copeand

Manager of Susan
Jessica Mullen
Level1

Manager of Jessica
Henry Jones
Level2
CONFIGURING MANAGEMENT & LINE MANAGER
HIERARCHY
CONFIGURING MANAGEMENT & LINE MANAGER
HIERARCHY
JOB LEVEL BASED
POSITION HIERARCHY
USERS
REPRESENTATIVES
REPRESENTATIVES (CONT…)
APPLICATION ROLE
APPROVAL GROUPS
EXAMPLES
Manage Salary Transaction:
- Salary < 5%
- Salary > 5 %

Promote:
- US1 Legal Entity
APPROVAL NOTIFICATIONS

TBD
BPM WORKLIST
Use the BPM Worklist to:

- Configure notifications, including when notifications are

issued
- Configure process details, such as expiration and escalation
policies
- Define approval groups
- Define approval rules in advanced mode

Note: The HCM Simplified UI (Manage Approval Transactions) does not allow you to modify rules that
were created using Advanced Mode in the BPM Worklist. If you originally created your rule conditions
using Advanced Mode in the BPM Worklist, you must continue to use the BPM Worklist to make
changes.

The application role that allows an administrator to view all human tasks is “BPM Workflow System
Admin Role”.

“Human Capital Management Application Administrator” role inherits this role by default
BPM WORKLIST
BPM WORKLIST
The following is a short list of activities that are commonly part of tailoring an
Enterprise Application and provides confirmation if this is possible for an
Oracle Cloud / SaaS deployment, and in which release
 BPM WORKLIST
Oracle BPM Worklist is a web-based application that lets users access tasks assigned to them and
perform actions based on their roles in the approval process. Oracle BPM Worklist supports the
following profiles:

•Work assignee - An end user who is assigned a task. These users can view tasks assigned to them
and perform actions, and also can define custom views and define routing rules for their tasks.

•Process owner - Typically a business analyst responsible for managing certain types of approvals.
These users can manage tasks for the processes they own, define approval groups, and change
approval policies

•Workflow administrator - Typically a system administrator responsible for managing errored tasks,
and administering and monitoring work queues. This user also may use Oracle Enterprise Manager
to monitor the health of the workflow services.
TASK
A task handles approvals. A different task is created for each approval requirement
based on the business served by it.
Some of the standard metadata for a task include the following:

- Task attributes such as title, outcomes (approve, reject, and so on) priority, expiration and
others
- Expiration and escalation policy
- Notification settings for notifying various participants
- Approval task configurations, including policies for substitution and modification of
approvers, configuration of self-approval, and repeated approvers.
 TASK - OPERATIONS
Most of the standard human task operations also are available on AMX-based tasks. Some of the common
operations include the following:

User-defined outcomes - Business outcomes, such as "Approve" and Reject," that are associated with a task.
When a user performs these types of actions, the task is removed from the user's "Inbox" and is marked as
completed or moved to the next approver.

Delegate - Allows a user to assign a task to another person or role to act on his or her behalf.

Escalate - Allows a user or an administrator to escalate a task to the user's supervisor.

Reassign - Allows users to transfer a task to another user. From that point on, the new user's hierarchy is
used for supervisor or other organization-based approvals.

Withdraw - Allows the task initiator or administrator to cancel or withdraw the task after the approval has
started.

Request for Information - Allows a task approver to request information from any prior participant or the task
initiator.

Pushback - Allows the task approver to push back the task to the previous approver to review it again.

Adhoc Insertions - Allows any task assignee to insert approvers in the generated approval list.
 BUSINESS RULES FOR APPROVAL
- Approvers of a task can be defined either inline in a task definition or by using business rules to specify
the list builders that identify the actual approvers of a task.

- In addition, we can use business rules to specify approver substitution and list modifications. These rules
are defined with the help of Oracle Business Rules and can vary between organizations. Typically,
however, they are defined by the customer.

- Business rules are a combination of conditions and actions.

- Rule actions consist of approver list builders and their parameters. Approver list builders move up a
particular hierarchy and construct or modify the approver list according to the parameters defined.
Approver list builders are implemented as XML (JAXB) fact types.
 BPM FUNCTIONS
HierarchyBuilder has a number of functions including getManager, getPrincipal,
and getManagerOfHierarchyPrincipal.

Function1:
HierarchyBuilder.getManager builds an approval list and takes the following
parameters:

ListbuilderType - String - can be "supervisory"," joblevel" or "position"

ReferenceUser - String - for example "Task.creator"
AssignmentID - long - the default value is -1, otherwise it is set to the user
EffectiveDate - String - for example, "2015–07–31"
HierarchyType - String - specifies the type of manager to look for when the list is
built. Example values are "LINE_MANAGER", "RESOURCE_MANAGER",
"CORPORATE_MANAGER", "PROJECT_MANAGER“

An example HierarchyBuild.getManager call is

HierarchyBuilder.getManager("supervisory",Task.creator,-1,"2015-07-
31","LINE_MANAGER")
 BPM FUNCTIONS
Function2:
HierarchyBuilder.getManagerOfHierarchyPrincipal locates top approver in an approval
list. It takes the following parameters:

PrincipalName - String - can be "supervisory"," joblevel" or "position“

Approver – Approver hierarchy
AssignmentID - long - the default value is -1, otherwise it is set to the user
EffectiveDate - String - for example, "2015–07–31"
HierarchyType - String - specifies the type of manager to look for when the list is built.
default is "LINE_MANAGER". Other possible values are "RESOURCE_MANAGER",
"CORPORATE_MANAGER", "PROJECT_MANAGER“

HierarchyBuilder.getManagerOfHierarchyPrincipal("supervisory",HierarchyBuilder.getM
anager("supervisory",Task.payload.transactionApprovalRequest.Requestor,-
1,null,"LINE_MANAGER"))
 BPM FUNCTIONS
Function2:
HierarchyBuilder.getPrincipal locates an approval list member and can be used, for
example, to identify the top approver in an approval list. It takes the following
parameters:

PrincipalName - String - can be "supervisory"," joblevel" or "position"

AssignmentID - long - the default value is -1, otherwise it is set to the user
EffectiveDate - String - for example, "2015–07–31"
HierarchyType - String - specifies the type of manager to look for when the list is built.
default is "LINE_MANAGER". Other possible values are "RESOURCE_MANAGER",
"CORPORATE_MANAGER", "PROJECT_MANAGER“

Ex:
HierarchyBuilder.getPrincipal(GetManager("LINE_MANAGER",Task.payload.Worker's
Current Assignment.result.Assignment Supervisor),-1,null,"LINE_MANAGER")
 BPM WORKLIST
Sample Rule for Transfer
Field Predefined Value Description
Condition Task.payload.Requestor's = "Sales West US"
Assignment.result.Department

List Builder Supervisory Determines the list of approvers using the

employee supervisory hierarchy, which is
defined in Oracle Fusion Human Capital
Management.
Response Type Required Indicates that approval notification requires a
response.
Number of levels 1 Specifies that one supervisory level is
required to complete invoice approval.
Starting Participant HierarchyBuilder.getManager("supervisory",G Identifies the first participant in the list of
etManager("LINE_MANAGER",Task.payload. approvers. For this rule, the first participant is
Worker's Current the supervisor of the user who submitted the
Assignment.result.Assignment Supervisor),- request.
1,null,"LINE_MANAGER")
Top Participant HierarchyBuilder.getPrincipal(GetManager("LI Specifies the user name of the last approver.
NE_MANAGER",Task.payload.Worker's Approval does not go beyond this participant
Current Assignment.result.Assignment in the hierarchybe sent.
Supervisor),-1,null,"LINE_MANAGER")

Auto Action Enabled False Indicates that automatic approval is not

enabled.
Auto Action Null Identifies the outcome to be set. The value is
null because automatic approval is not
 BPM WORKLIST
Sample Rule for Transfer
Field Predefined Value Description
Condition Task.payload.Requestor's "Sales West US"
Assignment.result.Department

List Builder Supervisory Determines the list of approvers using the

employee supervisory hierarchy, which is
defined in Oracle Fusion Human Capital
Management.
Response Type Required Indicates that approval notification requires a
response.
Number of levels 2 Specifies that one supervisory level is
required to complete invoice approval.
Starting Participant HierarchyBuilder.getManager("supervisory",T Identifies the first participant in the list of
ask.payload.transactionApprovalRequest.Req approvers. For this rule, the first participant is
uestor,-1,null,"LINE_MANAGER") the supervisor of the user who submitted the
request.
Top Participant HierarchyBuilder.getManagerOfHierarchyPrin Specifies the user name of the last approver.
cipal("supervisory",HierarchyBuilder.getMana Approval does not go beyond this participant
ger("supervisory",Task.payload.transactionAp in the hierarchybe sent.
provalRequest.Requestor,-
1,null,"LINE_MANAGER"))

Auto Action Enabled False Indicates that automatic approval is not

enabled.
Auto Action Null Identifies the outcome to be set. The value is
null because automatic approval is not
enabled.
BPM FAQ’S
How can a user identify which version of an approval task shown in the list of
HCM tasks in BPM will be used by the approval process ?

Ans. Approval tasks shown in BPM may list a number of approval tasks with the
same name, these are differentiated by a version number. The list shown is
controlled by an attribute - Active Versions - which can be changed by selecting
the Show check box in the list.

Note: The approval task invokes a composite webservice which can be seen from
Enterprise Manager (EM) and BPM. There may be more than one composite and
this is controlled by a version number as described previously. Older versions will
remain active until retired. When a new composite is deployed by applying a
patch, this composite will be defined as the default composite and new approvals
will then be processed by the default composite. Existing transactions may still
have to be processed by the older composite which must be active though it is no
longer the default (no new transactions will be processed by it).