Workflows - the Boring Part

Fifteen minutes reading about workflows? With no code samples? In today’s world? Really?

Yes, I know… my kids would yawn and never go past the first paragraph. However, I still believe that understanding of basic principles outweights the “instant” approach. At the end of the day, depending on you, the code and technical recipes will follow if you indicate that they would be useful enough (see details below).

Introduction

How many times did you hear the following descriptions:

• We receive an invoice from our vendor, and it is routed to different people to decide whether payment should be made.

• Employees are sending vacation requests that need to be reviewed by several people before they are granted.

• After a business trip, employees submit an expense report to their manager, who decides its validity with the finance department.

• We create outbound documents that need to be reviewed and digitally signed before they are dispatched to the third party.

• We receive inbound documents that need to be forwarded from the top-level management to employees who should handle them and provide answers in a written form.

Although they might sound different enough, they do share a common characteristic: there is an instance of a business entity (invoice, vacation request, expense claim, outbound or inbound document) that needs to be reviewed or approved, typically by several people, before it reaches the final state (approved, rejected, not relevant, or so.).

Let’s give a generic name to these instances - for example, Subject of Review and Approval (SRA) - and recognize that software solutions can help us speed up the described process. Historically, there were two main approaches to this matter:

• State machines

• Business process management (BPM) workflows

State Machine vs BPM

Historically, developers have a way to tackle the workflow requirements by defining different states of the SRA instance (represented by their statuses) and a matrix of allowed transitions from one status to another. Subsequently, they would implement the business rules related to which users or groups can perform particular sets of actions on a particular SRA instance, depending on its state.

This "state machine" approach can work fine from a functional point of view, but it also commonly fails when it comes to some more complex requirements, such as:

• Change the workflow after it has been initially deployed. Instances that have been already launched should follow the existing pattern, while new instances should follow the new one.

• Implement the logic which will be used to handle the out-of-office or reassignment patterns (see the chapter Common Concerns, later in the document).

• Provide the image of the current workflow instance state, or at least the image of the workflow design for documentation purposes.

• Route the process to several branches (sub-processes) at the same time,.

• etc.

Common BPM Platforms

Today, we can leverage different BPM platforms to achieve the above-mentioned goals. Within the Oracle APEX context, I had the opportunity to use, or at least to get familiar with, the following solutions, serving the same purpose (with Pros and Cons reflecting only my personal view, based on more or less experience or knowledge, depending on the technology):

As “promised” in the title, this will be a “boring part” of the workflow story, with no technical particularities. However, if there is an adequate response from the potential audience, I am more than happy to describe the usage of Oracle BPM Suite, Flows for APEX, or APEX Workflow in the following blog posts. So, if you are interested in some more details about leveraging some of these three platforms with Oracle APEX, please post the appropriate comment indicating your needs and the dedicated blog post will be considered.

Unless stated differently, the principles outlined in the rest of the document can be applied to any BPM platform.

Key Steps in the Business Process Execution

Typically, the full cycle of the workflow execution would comprise of the following steps:

• Record the SRA instance with necessary metadata values.

• Launch the BPM process instance related to the specific SRA instance.

• Perform BPM process activities in a designed sequence, until the final outcome is reached.

• Record the final outcome related to the specific SRA instance.

As simple as that, right? So, let’s now dive in the common recommendations relating to the design of each individual step.

Diagram 1. (part of the) BPM process example in runtime

Step 1 - Record the SRA instance with necessary metadata values

Of course, it goes without saying that we need a proper DB structure to store the data about SRA instances and corresponding application pages that support CRUD operations. Regardless of the SRA instance type, we want to pay attention to the following questions and make appropriate decisions:

• Do we need to record the data only at the header level (document), or do we need to record line items (invoice, expense claim)?

• Do we need to attach files to the recorded SRA information (for example, the receipt scan for expense claims)? At the header or line level?

• We must provide the possibility (and obligation) to enter all the metadata that could impact the BPM process flow (for example, an invoice amount, if invoices above a certain amount will be routed differently).

• Is the person recording the data in the application always the same as the person the data is related to? Maybe we have field workers without access to the application, and we need their administrative counterparts to record the vacation requests on their behalf. If so, how will they communicate (outside of the application) when decisions are made?

• Almost always, we will need information about the Status of the SRA instance. Typically, the basic (minimal) set of statuses will be:

  • DRAFT - the data entry step.

  • SUBMITTED - the workflow instance has been launched.

  • APPROVED - positive final decision.

  • REJECTED - negative final decision.

• We need an easy way for a user to search through recorded SRA instances, being able to identify instances created by or related to him/her and their basic information, such as statuses.

Step 2 - Launch the BPM process instance related to the specific SRA instance

• By entering any individual SRA instance, the user should be able to modify the data while it is in DRAFT status. Once a user decides to launch the process, the status changes to SUBMITTED, and the SRA instance should become read-only until the process is completed, i.e. until the final decision is made.

• Once the process is launched, we need to record the unique relationship between the process instance ID and the SRA instance ID. Typically, we would do that in a manner that allows us to edit this relationship once the process instance is completed by recording the completion date/time and the final outcome.

• The process data have to include all information needed to support making decision by users, or eecuting relevant service tasks. In other words, it might be enough to keep the SRA primary key as the main piece of process data, alongside with any information created during the process execution itself.

• At any particular point in time, the user should be able to see the current phase of the process execution and the person(s) currently responsible for taking the action.

Step 3 - Perform BPM process activities in a designed sequence until the final outcome is reached

Yes, the fun part… so once the process instance has been launched, we execute different service or human activities previously outlined in the BPM process diagram. While service activities are related to the running of different automated procedures during the process execution, we are going to remain focused on the human activities that assume the interaction with application users, i.e., decision-makers, in routing the process flow. Let’s make sure to pay attention to the following considerations:

• User needs to be able to easily access the list of tasks waiting for his action, so we need to build an appropriate task list. Depending on the BPM solution we are using, the methodology and queries will obviously be different, but the ultimate goal is to provide a list of current tasks.

Diagram 2. Task list example

• When the user picks the task that he wants to work on, typically, we will open the so-called task form (some BPM platforms have the possibility to generate at least the basic template of the task form). This form needs to contain:

  • Information about the SRA instance related to the BPM process instance to which the task belongs. We need to display all the necessary information (including attached content) for the user to make the decision.

  • The possibility of seeing the process instance execution context, such as previous tasks, comments, and a process diagram.

  • The possibility of recording the comments related to the particular task, but at the same time to the process instance. These comments should serve to elaborate the task outcome (why did I returned the task, why did I reject the SRA instance, what I would like to be done at the next step…).

  • Sometimes, we can implement the “routing results”, which will be added automatically once we record the task outcome (for example “the expense claim was forwarded to X by Y”). This way, users will be able to track the process history in the more “natural” way, without even inspecting the process history table.

  • Record additional metadata values if needed (for example, the finance department might need to record the account details for the submitted expense claim during the process).

  • The possibility to record the task outcome.

Diagram 3. Task form example

• Typical task outcomes are:

  • APPROVE - the positive decision about the SRA instance approval has been made.

  • REJECT - the negative decision about the SRA instance approval has been made.

  • FORWARD - The SRA instance is routed to the next step of an approval process without a final decision.

  • RETURN - The SRA instance is routed to the previous step of an approval process, typically if the user does not agree with the information entered or the decision made within that step.

• Although typically human activities will involve decision-making, sometimes we will create tasks just to make sure that:

  • some actions are performed (“The document has been approved; please scan the final version”) or

  • users are notified of significant events (“The expense claim has been approved”).

without impacting the process instance routing (FYI tasks). In these cases, the user will have only one possible outcome (such as OK or ACKNOWLEDGE).

• Once the task outcome is recorded, we send this information to the BPM platform we are using so it can complete the task and proceed with the process execution. The task lists need to be refreshed (make sure that queries are performant enough), and the completed task will disappear from them. Unless the process is completed, a new task will be generated for another user.

• Human activity can be routed to the user or the group(s) of users. If it is routed to the group, every member can complete it, but before that, he must CLAIM the task to prevent multiple users from bringing (different?) decisions at the same time. If the user abandons the already claimed task, they can RELEASE it. From the task form point of view, we will typically not allow any action to be performed before the task is claimed.

Step 4 - Record the final outcome related to the specific SRA instance

Once the final activity has been completed, we will reach the final decision about the SRA instance, and the process will be finished. We will typically record that information alongside the relationship between the SRA instance and the process instances (established within Step 2), send appropriate notification(s), or maybe even trigger interactions with other systems (for example, send the approved invoice to ERP, or so).

Common Concerns

As of today, the BPM process is not always the most welcomed paradigm in some organizations since it can be considered too complex or too rigid. Of course, when implemented correctly and mindful of the physical process that is currently going on, it will bring nothing but gain. So, let’s dive into some common concerns of our users and recommendations on how to overcome them.

Last but not least… keep in mind that all these concerns are not a consequence of BPM but an inheritance from real-world physical processes, potentially only revealed when BPM is implemented. So, the technology is there to assist, not to introduce more uncertainty.

Diagram 4. Imagine altering the metadata after the approval process has already been launched.

Instead of the Conclusion

Thank you for your attention and patience! Whether you consider this article as fifteen wasted minutes of your life or hours of saved time, feel free to mention that in the comments. Let us know about your thoughts and experience with BPM implementations, as I firmly believe that the majority of them are yet to come.