What is a Human Workflow?
Human Workflow is the component of Oracle’s SOA suite that allows humans to interact with a process. For example a manager might need to approve a purchase order or an expense report prior to the transaction (issuing a purchase order or reimbursement of expenses) being completed or perhaps to reassign a task they are unable to complete. In addition to allowing users of an application to interact with its processes, the capabilities of the Human Workflow include full task lifecycle management through the ability to reroute tasks, escalate them, and providing deadlines by which they must be completed, in addition to the presentation of tasks to the concerned user through the BPM Worklist application or other channels such as email.
The Task and its Rules
In our example we will use a Fusion HCM Transaction example to illustrate how a transaction is routed and what actions an administrator can take on that transaction.
The Table below lists Fusion Core HCM transactions that are enabled for approvals.
Seeded Approvals (Include 2 Levels of Supervisor chain) | Seeded Auto-Approved |
Transfer | Manage Salary (typically configured to require approval) |
Promotion | Manage Compensation (typically configured to require approval) |
Change Manager | Share Information (requires approval by worker) |
Change Location | Change Marital Status |
Change Working Hours | Create Employment Terms |
Terminate Work Relationship | Manage Employment |
Hire an Employee | Manage Grades |
Add a Non-worker | Manage Grade Ladders |
Add a Contingent Worker | Manage Grade Rates |
Add a Pending Worker | Manage Jobs |
Create Work Relationship | Manage Locations |
Manage Work Schedule Assignment | Manage Organizations |
Manage Absence Records (1 level) | Manage Person |
Manage Document Record (1 level) | Manage Positions |
Submit Performance Document(1 level) | |
Add Goal (1 level) |
Table 1.Fusion HCM Transactions
Let us start by looking at the Promotion Task and the rules associated with that task.
Figure 1 shows the composite process that handles the HCM Promotion task. This composite consists of several SOA components and includes the services and references in Figure 2.
Figure 1.Deployed Promotion Approvals Composite processes.
Figure2. Components of the Promotion Approval Composite
In Figure 3 below, the rule defined reads as follows: For the promotion process and for all cases (the condition 1=1 being always true) build the approval list based on the supervisory hierarchy and process the transaction two levels above the approver, starting with the approver’s manager and stopping with the user “douglas.mcneil” who happens to also be the CEO and the top node in the hierarchy.
Figure3. BPM Task Configuration Rules
The Administrator’s privileges
In Fusion Applications the ability to access functions across products is controlled by functional privileges granted to a user through APM (Access Provisioning Manager). The application role that allows an administrator to view all human tasks is “Business Process Human Taskflow Administration Duty”. The table below shows the hierarchy that inherits this duty role in the seeded security implementation.
Level | Display Name | Role Name | Description | Inherited by |
1 | Human Capital Management Application Administrator | HRC_HUMAN_CAPITAL_ MANAGEMENT_APPLICATION_ADMINISTRATOR_JOB | Configures the Oracle Fusion Global Human Resources application and has access to all duty roles necessary to implement the Compensation, Workforce Deployment, and Workforce Development offerings. | |
2 | Business Process Human Taskflow Administration Duty | SOA_BPM_WORKFLOW_ADMINISTRATOR_DUTY | This role grants a user the privilege to perform administrative actions in the workflow functionality via the worklist UI. A user in this role will be able to view all tasks in the system, recover errored (incorrectly assigned) tasks, create approval groups and edit task configuration / rules DT@RT UI (both AMX functionality) This is a business administrator type role. This role is granted to SOAAdmin. | 1 |
Table 2.Seeded Roles that provide access to all Tasks in the Worklist application
Figure4. Role hierarchy assigned to the administrator for the example in this document
The HCM Transaction
At the conclusion of a performance evaluation cycle, a manager determines that an employee is a candidate for a promotion. The Manager initiates the request from the Manager Resources Dashboard. The necessary adjustments are made to the employee’s Job, and Compensation details and the transaction is submitted.
Figure5a. Supervisory Hierarchy: Donald Alexander reports to Douglas McNeil
Figure5b. Supervisory Hierarchy: Stella Marcus reports to Donald Alexander
Figure5c. Supervisory Hierarchy: Jaime Gregg reports to Stella Marcus
Figures 5a, 5b, 5c show three levels in the supervisory hierarchy, the transaction we will use in our example below will be submitted for employee Jamie Gregg, and will be submitted by Stella Marcus her manager. Based on the approval rules we had defined earlier this promotion request will be routed to the next two levels in the hierarchy in sequence to Donald Alexander then Douglas McNeil.
The manager selects the Promote Action from the employee’s card in the Org chart
Figure6. The Manager Selects the Promote Action from the Org Chart.
The Manager Completes the promotion request and reviews the details prior to submission. The approval list is built in the last step of the transaction as illustrated in Figure 7a and 7b below.
Figure7a. There last step in the transaction is the review of the request prior to submission
Figure7b. The Approval list built in the last step of the transaction prior to submission.
Initiated transactions generate an instance of the composite process discussed earlier (see Figure 8 below) , and are available to the participants and administrator. The instance also retains the status and history of the transactions during its lifecycle and after completion.
Figure 8. TheTask instance in the Worklist of the Manager
After submission, the manager can review the initiated task and amend it by adding attachments or comments as seen in Figure 9 below.
Figure 9. Comments and Attachments added to the request
The Notification
Based on the rules applicable to the promotion transaction we discussed earlier, the process sends a request for approval to the manager of the requestor. However let us assume that Donald Alexander the manager of Stella Marcus and the the first of the two approvers is not available to take an action on the request. Stella makes a request via the comments field to have the administrator to skip the current stage and forward the request to the next approver.
The Administrator Action
The administrator Kyle Bailey searches for transactions assigned to Donald Alexander (Figure 10) and can perform the actions listed in Figure 11 namely skip the current assignment, suspend , withdraw or reassign the request to a different user .
Figure 10. Administrator queries tasks assigned to Donald Alexander
Figure 11. Actions an administrator can take on an assigned task
After reassignment of the task by the administrator to the next approver, Douglas McNeil can now see the Task in their worklist.
Figure 12. Worklist of the user to whom the task was reassigned
All changes made to to a task instance remain with the task and are viewable by all users who have access to that task namely the participants in the transaction (the approvers) and the administrator. A completed task with a full history of task actions and the participants who made them is shown in Figure 13 below.
Figure 13.Completed Task