How to implement Complex Approval Schemes

How to Implement Complex Approval Cycles

Introduction

Flows for APEX allows you to create almost any complex approval cycle that you need for your organization. This page will describe how to implement these complex schemes, using the components available to you, including:

• APEX Human Tasks (Approval Tasks)
• BPMN
• Flows for APEX expressions and variables
• Flows for APEX Loops and Iterations (* Enterprise Edition feature).

Let’s get started…

Sequential Approval Flows

Flows for APEX can be used to create business processes containing approval rules. We’ll start with a simple business process where content gets created by an originator, and then sent to a manager for approval. If the manager approves, we then check that the manager has the authority to be the final approver on this item, in which case we are finished. If it requires further approval, it can be sent. to a SVP for her approval.

This is all very easily achieved with Flows for APEX, and we can use the APEX Human Task features in Oracle APEX to very rapidly generate task lists and task detail pages as part of your APEX application. With BPMN gateways, its very easy to create whatever arbitrary approval path and logic that your application needs. This paper will look at more complex approaches, were we want to implement concepts like:

• approvals by multiple approvers in parallel
• parallel approvals by a non-predetermined sized group
• ‘all must approve’, ‘anyone can reject’, ‘majority rules’ and other decision criteria
• delegation, referral, requests for more information
• vacation and alternate users
• reminders and escalations
• due dates and priorities

So let’s move on to the more advanced ideas….

Parallel Approvals

We’ll do this an easy way with a pre-determined number of approvers first. Then show how this can be generalized to an arbitrary number of approvers using parallel iterated tasks (an Enterprise Edition feature).

Approach 1 - Pre-Determined Number of Approvers

Requirement: Have 3 managers approve an item in parallel.

Solution: This is fairly straight forward with Flows for APEX, which supports parallel and conditional parallel (inclusive) BPMN gateways, allowing us to have tasks occurring in parallel.

We’re going to implement this two ways. The first case is “hard-wired” and the task will always be assigned to exactly 3 managers.

Each of the approval user tasks is implemented using an APEX Approval Task. We actually use the same task definition for all three of the approvals, but use the assignment definition in the BPMN to assign each of the tasks to different users, based on our business logic.

The BPMN User Task for Manager Approval 1 is configured in the diagram below. The Task Subject is being pushed from the workflow (as ‘Manager Approval 1’).

And the task is assigned to one Potential Owner, Blake, using a Static Assignment to one of our managers in EMP. You could use a query on a expression to set this to somebody else using logic that makes sense in your organization. Similarly, the workflow can assign a Business Admin for the task.

Outcomes. Each of our 3 approvals return its approval outcome, APPROVED or REJECTED , into a Flows for aPEX process variable according to the task configuration. You can see from the screenshot above that our task 1 returns its outcome to MGR_OUTCOME_1. Our other tasks return their outcomes into MGR_OUTCOME_2and MGR_OUTCOME_3. How to combine them?

In this case, the business rule was that all 3 managers must approve for the item to be approved. How to implement that? We’ve simply used a variable expression that fires AFTER MERGE in the closing parallel gateway object ( ) named ‘Merge and Tally Votes’ to create an overall outcome, FINAL-OUTCOMEusing logic that requires all 3 outcomes to be APPROVED. We’ll come back to this concept later to implement more complex ideas…

Approach 2 - Query-Driven using Parallel Iterations

In our second case, we’re going to implement parallel approvals where all managers must approve in parallel. In this case, however, rather than hard-coding 3 parallel paths, we are going to use the BPMN task multiple instantiation feature - where the group of approvers is defined by a query, and we don’t know in advance how many approvers there will be be.

Our model is actually now much simpler…

Note that our Approval how has the parallel multi-instantiation marker on it. ( ) . This denotes that this task occurs multiple times, in parallel. Let’s take a look at the task definition for the Manager Approval…

The APEX Human Task is as before, except the outcome is now named MGR_OUTCOME. But if we look scroll down the properties panel and look at the Multi-Instance and Assignment sections, in the screenshot below, we can see that this is different.

Looking at the Multi-Instance section, we can see that the iteration is defined with an input collection which is a SQL Query that selects all of the managers from our EMP table. When the process is executed, each row returned by the query creates one parallel copy of the task. Each of the selected rows returns ENAME, EMPNO, and a DEPTNO. These values will be created as Flows for APEX process variables that can be used by the relevant copy of the task. The multi-instantiation creates a JSON array containing all of the input and output variables for each of the copies. This JSON array will be stored in a Flows for APEX JSON-typed process variable - in this case named APPROVAL_ARRAY. And we’ve specified that the variable MGR_OUTCOME from each copy will also be added to the array.

Looking at the Assignment section. We’re going to use the manager’s username for each of the approving manager for task assignment. So our ENAME from the input collection is used to assign the task to the manager in the Assignment section. You can see that Potential Owners is now set to ENAME.

This is all that is required to set up a task to be created and operated in parallel by some arbitrary, query-defined set of users.

If we run this process, this creates an approval task for each of our managers. Using the Flows for APEX Task monitor, and look at the Task List Entries tab, we can see that our process is currently creating four task list entries, one each for CLARK, JONES, BLAKE, and BO.

We need to change one more thing before our process is ready togo.. We still need to get to our majority decision from the four individual manager’s approvals. We’ll do this by adding a variable expression in the exclusive gateway that follows our parallel section that calculates a process variable FINAL_OUTCOME - in this case, if all of the manager approvals are APPROVED, the final outcome will be ``APPROVED, otherwise REJECTED`. Obviously you could create your own logic here to d majority rules, or whatever.

Our full code in the gateway BEFORE SPLITvariable expression that creates a process variable FINAL_OUTCOME is as below:

declare
    l_json        json_element_t;
    l_array       json_array_t;
    l_item        json_object_t;
    l_mgr_outcome varchar2(50);
begin
    -- Get the JSON process variable as a JSON element
    l_json := flow_process_vars.get_var_json_element(
                 pi_prcs_id  => flow_globals.process_id,
                 pi_var_name => 'APPROVAL_ARRAY'
              );

    -- Cast to array
    l_array := treat(l_json as json_array_t);

    -- Loop through each item
    for i in 0 .. l_array.get_size - 1 loop
        l_item := treat(l_array.get(i) as json_object_t);

        -- Get MGR_OUTCOME from outputVariables
        l_mgr_outcome := upper(
            treat(l_item.get_object('outputVariables') as json_object_t).get_string('MGR_OUTCOME')
        );

        -- Check outcome
        if l_mgr_outcome != 'APPROVED' then
            return 'REJECTED';
        end if;
    end loop;

    return 'APPROVED';
end;

After running this, with one manager rejecting the task, here is a copy of the Output Collection JSON so that you can see how an iteration output collection works.

[
  {"loopCounter":1,
  "description":"Manager Approvals",
  "inputVariables":{"ENAME":"CLARK","EMPNO":7782,"DEPTNO":10},
  "stepKey":"PeFDXTPrMe",
  "status":"completed",
  "subflow":91,
  "outputVariables":{"MGR_OUTCOME":"APPROVED"}
 },
 {"loopCounter":2,
  "description":"Manager Approvals",
  "inputVariables": {"ENAME":"JONES","EMPNO":7566,"DEPTNO":20},
  "stepKey":"xISdmBtmNO",
  "status":"completed",
  "subflow":92,
  "outputVariables":{"MGR_OUTCOME":"REJECTED"}
 },
 {"loopCounter":3,
  "description":"Manager Approvals",
  "inputVariables":{"ENAME":"BLAKE","EMPNO":7698,"DEPTNO":30},
  "stepKey":"JAvOTvAgHc",
  "status":"completed",
  "subflow":93,
  "outputVariables":{"MGR_OUTCOME":"APPROVED"}
 },
 {"loopCounter":4,
  "description":"Manager Approvals",
  "inputVariables":{"ENAME":"BO","EMPNO":8900,"DEPTNO":40},
  "stepKey":"kLbXPnJokl",
  "status":"completed",
  "subflow":94,
  "outputVariables":{"MGR_OUTCOME":"APPROVED"} 
 }
]	

We could easily write more sophisticated vote tallying methods here, to implement tallying methods such as:

• All must Approve
• Any n can veto to Reject
• Majority rules

Using multi-instantiated / iterated tasks gives us a powerful way to model situations were some arbitrary, query-defined, number of participants need to perform an operation (or a task needs to be performed on some arbitrary, query-defined number of objects).

More Information on Iterations - See product documentation here.

Approval Task Functionality.

APEX Human Tasks have their own powerful set of functionality, driven by a task state model. Use of these APEX Human Tasks allows a Flows for APEX developer to get a powerful set of task functionality out of the box, without further development work. The APEX Application Builder allows a developer to generate various pages to create highly functional application pages that are visually appealing to implement task detail pages for each task, and a task list where a user can see her current tasks and launch the appropriate task detail page.

Here is an overview of some of the capabilities that these tasks provide, which we will discuss briefly in this section. The full features of APEX Human Tasks are documented in the Oracle APEX Application Developers Guide chapter on Workflows and Human Tasks.

• Task Reservation. Tasks can have one or more potential owners. One of these potential owners can claim or reserve a task, at which point they become the actual owner. A task with only one potential owner automatically makes that owner the actual owner. The actual owner can also release a task.

• Delegation. The actual owner of a task is able to delegate a task to another potential owner, who the becomes the actual owner.

• Request to the Originator for More Information. The owner of a task can request further information from the task originator. This causes the task to be assigned back to the originator, requesting more information. The supplied information is added to the task-level commenting system, and the task returned to the requestor when the originator completes the request task.

• Vacation Assignment Rules. APEX Human Tasks now include vacation assignment rules, defined at either APEX application level, or at the APEX Human Task level. Task level takes precedence over application level. If a vacation rule is defined for a user and the user is away, the vacation rule adds an additional potential owner to the task - so the original potential owner can still decide to complete a task themselves, or to allow the delegate to take ownership.

  Depending on the organization and the existence of any system of record for vacation or travel absence in the HR system, you could write functions in the HR to publish absence and delegation information, which could then be used by the workflow. Other, less formal, organizations might add delegates to the potential owners list anyhow - so that a manager and her delegate can always cover each other.

  More information on Vacation Assignment: see Ananya Chatterjee’s article on Oracle APEX Blogs.

• Add a Potential Owner. A Business Admin is able to add a potential owner to a task after it has been created.

• Task-level Commenting. APEX Human Tasks include a commenting system, where a task owner can add comments to a task at any point. These comments are available to subsequent owners of the task. Note that these are TASK level, and comments are not available to owners of other tasks in the same process. For example, if a series of approvals are made in sequence, the comments from the first approval by a manager are not visible to the second, VP approver. You could build process-level commenting in your application, of course, if you needed it (but there are often privacy and related visibility issues that you need to think about if you do this!).

• Task-level History. The APEX Human Task keeps its own history trail, which is (by default) visible to users of the task, and can be archived subsequently. Flows for APEX does not currently collect this history after the task completes and add it to the process logs.

• Unified Task List. This can be generated by APEX with a few clicks, and provides a workspace-level task list. To include Flows for APEX tasks, this can be customized in a few minutes so that all tasks are handled in the task list. See instructions.

APEX Human Tasks have their potential owners and business administrator defined when the task is created, i.e., when it becomes the current object in a workflow. These assignments can be built into the task definition, or can be pulled from the Flows for APEX workflow - see task configuration doc. All of these assignments can use SQL and PL/SQL to query other systems of record to make data-driven task assignment. For example, assignments could use:

• a directory service to find the originating employee’s manager or to find an approver by job title or post
• an HR system to get management hierarchy
• the approval matrix from a financial system to check whether an approval is within a cost center owner’s authority limit, or whether it needs to then be approved by a more senior executive
• a shift / rostering system to assign tasks to someone who is on shift
• a vacation approval system to know that an approver is away

Priorities, Due Dates, Reminders and Time Outs

Another set of requirements for approvals and other human tasks comes around priorities, scheduling, and what you do when tasks are not getting completed on schedule.

Flows for APEX and BPMN give us an additional set of tools for managing human tasks in this area.

Due Dates and Priorities

Flows for APEX allows you to specify a process due date for the entire process to complete, and a process priority, a 5 level scale from 1 (highest) to 5 (lowest).

In addition, a BPMN user task / human task can be given a task due date and a task priority, on the same 5 point scale. The task priority can be set to equal its parent process’ process priority.

The intension is that an external task, created by the organization, could be used to review how likely a task is to complete by its process due date, and if it is looking like it will not meet its required due date, then the process priority and individual task priorities could be increased so that it completes on time. That might be a useful application for AI in the future!

Task priority and due date are visible in the generated APEX Task List, are used for highlighting high priority or overdue tasks, and can be used to sort or filter a user’s tasks.

Reminders

BPMN gives us the capability to create highly flexible sequences of reminders and time-outs / auto approval/rejection scenarios. This is implemented by adding one or more BPMN boundary events onto a workflow activity – a task or a sub process. Here are some possible scenarios.

Simple Reminder. In our simplest example, we’ve added a non-interrupting timer boundary event ( ) on to our approval task. The timer is configured to fire after 2 days. When it fires, an additional path opens up on the workflow that causes the send reminder task to execute. Send reminder is a BPMN service task that uses the APEX mail system to send a reminder to the current owner.

Repeating Timer. We could make this timer repeat - so every day, the user will get another reminder. Now we’re going to send a reminder after 2 days, then send a new reminder every day after that - up to day 6.

Escalating Timer. After a week, we’e going to send an email copying the task owner’s manager. We do this by adding a second non-interrupting timer boundary event onto the task. This one is configured to fire for the first time after 7 days, and the repeat every day for a total of four runs.

Time Out / Auto Decision. If that still hasn’t got a decision after 12 days, we want to auto-reject the content. We can do that by adding another boundary event, this time an interrupting timer boundary event. When this timer fires, it will cause the parent task to be cancelled and the workflow to proceed down the path following the boundary event. We use a variable expression that fires on-event (i.e., when the. timer fires) to set the approval outcome MGR_OUTCOME to REJECTED.

Timer-based interrupting boundary events can also be used for other, more complex time-based events. For example, for a conference paper submission process, you could use an interrupting timer to close the submission period, collate received papers, ad automatically send them to the selection committee. Or to start end of financial quarter processing…