You are not looking at the latest version of the documentation. Check it out there.

Introduction

BPMN and Flows for APEX provide several features that allow you to model who should perform activities and tasks in a business process. These mechanisms include Lanes and Task Assignment. Both of these have been significantly enhanced in Flows for APEX v23.1.

Lanes

A BPMN model can optionally be drawn using a set of Lanes, which show the user or group of users responsible for the tasks in the lane.

Process example with Lanes

In this example, the process has three process lanes - Sales, Finance, and Shipping. Tasks in the Shipping lane would be performed by users in the shipping department, tasks in the Finance lane are performed by the Finance Department, etc.

Lanes can be further sub-divided with a set of child lanes. So our Shipping department could, for example, be further divided into 3 child lanes - ‘Shipping Manager’, ‘Warehouse Staff’, and ‘Freight Buyer’. Child lanes are supported from Flows for APEX v 23.1 onwards. Child lanesets are useful as you add more detail to your model.

Process example with Child Lanes

Lanes

At process runtime, the lane information for current tasks in a process instance is available to the application through the Task List and Task Inbox views.

Lanes and Roles.

At first glance, Lanes look as if they should map nicely to APEX Roles. However, on further investigation, you will discover that some Lanes map nicely to database or APEX roles, other lanes on your model are not useful in defining to whom exactly a task should be assigned.

In the BPMN Modeler, you can specify whether a lane does indeed map to a role, and if so, the name of that role. The Role information is then used as the default role for all tasks in the lane, unless they have more specific task assignment information defined.

Task Assignment. (new in v23.1)

In addition to the use of Lanes, tasks can be explicitly assigned to users or groups of users. Starting in Flows for APEX v23.1, Task Assignment information can be added to UserTasks. This allows the process modeler to define who can be assigned a UserTask. Tasks can be assigned to:

  • one or more Potential Users, and/or
  • one or more Potential Groups.
  • in addition, you can also specify one or more Excluded Users - which takes priority over any Potential Users and Potential Groups specified.

Like most object settings, the Potential Users, Potential Groups and Excluded Users can be specified using a variety of methods:

  • by static definition, ie., by providing a user name, or a colon (:) separated list of usernames.
  • by process variable, i.e., by specifying the name of a process variable of type varchar2 containing a user name, or a colon (:) separated list of usernames.
  • by a SQL query returning a user name, or a colon (:) separated list of usernames.
  • by a PL/SQL function body returning a user name, or a colon (:) separated list of usernames.
  • by a PL/SQL expression returning returning a user name, or a colon (:) separated list of usernames.

This allows you to create dynamic task assignment, assigning tasks to users based on process variables set up in earlier steps of a process, or from running queries on the underlying database. This could be used to implement business rules including allocation of tasks to a manager, allocation of task based on skill matching, language ability, current workload, shift patterns, deputization during periods of absence, etc..

Task Assignment and Task Reservation / Claiming,

In applications where users are provided with a task inbox, users will see all of the current tasks for which they are potential users or which they are members of any of the potential groups. As a result, a task can ofte appear in the inbox of many users. Task Reservation provides a mechanism for users to reserve, or claim, a task before they start to work on it. This prevents more than one user starting to work on the same task.

A Task List application and / or your application should provide a way for users to reserve tasks before they start work on the task. If you are using the APEX Unified Task List feature, in Oracle APEX v22.1 and later, some of this functionality is provided for you - but needs adaptation for Flows for APEX. See Using the APEX Unified Task List with Flows for APEX. **NEEDS LINK

User Tasks can be reserved, or claimed, from the API by calling the flow_api_pkg.flow_reserve_step procedure. When you reserve a step, you supply a reservation as the p_reservation argument. This would usually be set to the username of the user making the reservation - although an application might want to have some other scheme for reservation value.

A reserved / claimed task reservation can also be explicitly released by calling flow_api_pkg.flow_release_step procedure.

Reservation only applies to the current step on a subflow, and is implicitly released when the step is completed and the process continues to the next step, i.e., when flow_api_pkg.flow_complete_step is called.

The Flows For APEX Task Reservation is a light weight mechanism to signal to others that this task is reserved and will be worked on by the reserving user. Out of the box, it is not a security mechanism to prevent unauthorized users from working on a task. You should not solely rely on this mechanism to control task authorization or other access control objectives.

As part of your application design, you might want to wrap these procedures with your own application-specific controls to implement control on who can reserve (and for whom), and who can release reservations.

Using Lanes with Call Activities

A Call Activity is used whe one diagram calls another as part of a single process. The issue here is whether the calling diagram uses lanes, and whether the called diagram uses lanes.

With a Call Activity, the Calling Diagram may, or may not, have lanes. Similarly, the Called Diagram may, or may not, have lanes. There are no restrictions imposed by Lanes. If no lanes are present in the current diagram, lane information is inhereted from the calling task (if available).

Lane Behavior Called Diagram Has Lanes Called Diagram Has No Lanes
Calling Diagram Has Lanes Lanes are used from the Called Diagram All activities in the Called Diagram occur in the Calling Task’s lane in the Calling Diagram
Calling Diagram Has No Lanes Lanes are used from the Called Diagram No Lanes Are Used