I spent my first few years in software implementing JDEdwards.  I was fortunate to have clients in the distribution business.  JDE had a workflow management capability called Activity Rules.  Order Types were assigned to a set of Activity rules, that defined precedence and allowable outcomes between activities.  Very compact.  Simple in execution, but hard to visualize.  They had thought through how to make the application performant, while remaining very flexible.  Transactions always knew their state, and applications that worked on them had parameters that said what state they were looking for.  For example, the Proof of Shipment transaction could as easily be used as a Proof of Delivery capability.  However, this model was very linear.  It was difficult to spawn parallel streams of activity for a single transaction.  This limited its capability as a true process engineering tool. 

When I joined Oracle development, they had just released the Oracle Workflow tool.  It was built out of the Applications Technology team.  It was expected to be uptaken by many applications teams and may have had some uptake outside of Oracle Applications.  The intent was to be able to model a business process, and to be able to safely change the process at deployment time without code changes.   The design tool was very visual.  I started work on it with a set of predispositions toward the JDE model of activity rules.  This linear approach seemed very flexible and seemed to model customer requirements very well.   However, the designers of the workflow tool were very focused on the parallelism.  If you come from the process management world, removing dependencies, such that activities can run in parallel is very important.  It allows you to shorten cycle times.  

I was fortunate enough to have lead the effort to uptake Oracle Workflow within Order Management.  That application was going through a significant re architecture, and this was part of its modernization.  

Order Management is a very performance sensitive area.  Development managers were understandably nervous to be dependent on a central service.  There are some states in the Order Workflow that are particularly important: Is the Order Booked?  Is the Order Released for Picking? Is the Order Shipped?  These questions ended up being answered within the Order Management data model.  This limited the degree of flexibility that workflow could offer. However, simplicity and performance are requirements as well, so intelligent compromises have to be made. 

General Ledger had a very novel use for the workflow tool.  An account code in Oracle and every General Ledger system that I know is composed of multiple segments.  Different of these segments might come from different places.  Take an expense report.  The company segment might come from an employee’s employment.  The cost center might come from their current assignment.  The Account Generator gave you a visual tool for seeing and changing those rules without affecting the code of the application. Being an accountant myself, I thought this might be asking a lot of accounting staff, but other accounting configuration tools suffer from the same issue of being powerful rarely used tools.  It seemed much closer to visual programming than business process management. 

As an architect in Oracle, I got familiar with the Computer Aided Software Engineering tools.  CASE tools were a bit unpopular with developers.  As stated earlier, coders want to code, and the visual tooling of the Lower CASE tools seem in the way.  Worse than that, the process and data modeling tools in the Upper CASE world seem irrelevant and intrusive.  However for Architects and Designers they are the tools of the trade.  There were great capabilities within the process designer to do real process design work.  You could declare costs and capacity for resources consumed in an activity.  I never saw these capabilities well utilized in the marketplace though. 

Another little utilized capability within the Oracle universe was the Process Navigator capability in the eBusiness Suite menuing system.  If you are a novice user coming to the procurement system for example, you can click on the “Processes” tab in the menu system and see the Processes that Procurement supports:  Requisitioning, Sourcing, Purchasing.  You can start one of these processes and see the activities within the process and transitions between them.  You can click on an activity and go to the Form in EBS that is that activity. 

I was very keen on utilizing these workflows as the touchstone of the processes that we supported at the start of the Sarbanes Oxely wave, that gave rise to a category of software called GRC or Governance Risk and Compliance.  The counter to using Workflow was the Process Definitions that were in a Procedure Manual writing tool that Oracle sold at that time called Oracle Tutor.  We ended up building a bridge between the Tutor and Workflow representations of a process, but to be honest the market at the time was much more interested in having a procedures manual than a workflow tool. 

As middleware became a dominant theme in applications, the mantra of Oracle towards a Global Single Instance where everything resided resonated less.  We found ourselves living in a world where the theme was to co-existi with multiple applications all participating in a single process.  Oracle’s workflow tool was built from the perspective of EBS being the Dominant application with the ability to integrate with other applications.  For example, an order workflow might integrate with an Freight Forwarding service to check for Export Compliance. 

BPEL on the other hand, really saw all applications as equal participants and saw the integration between them as its central value. 

While we had all these processes in the Applications, and a library of them in the workflow and business process tools, it was not really until the Fusion Applications were being built that we made that library something that we showed to the world.  The Business Process Engineering team, did a great job of organizing and presenting business processes in a common hierarchy.  They did this in a way that both allowed a process to be verified outside of the application that housed it, as well as tying the process steps into the underlying screens and reports.

Flows for Apex took a great Web base Open Source BPMN drawing tool and embedded it into Apex.  It was done as an Open Source project by a set of Apex evangelists in Germany.  https://flowsforapex.org/team/

It read through the BPMN definition and created a Definition of the Flow within Apex.  

It was a great innovation and filled a need that I thought was in the Apex tool for a long time.  My guess is that the applause with which Flows for Apex was greeted, probably advanced Workflow within Apex, although to my eyes, Apex 23.2 gives more of a nod to Oracle Workflow than it does to Flows for Apex. 

What should the application look like?  Mendix is a good example of a tool that starts here.  The pallet is very free format, but it means that your layout is not free to adapt to different form factors or changing conventions.  

How should a user move through the application? Pega is a good example of a tool that starts here.  This vantage point is good for reviewing with end users to confirm the broad brush strokes of system behaviour.  

What information does the application use?  Apex has historically been a good example of a tool that starts here.  Reading a data model does not come naturally to most people.  However, if people are moving from a spreadsheet level of automation to an application, the first cut of the data model that the spreadsheets give you will help draft an application for refinement.

Oracle put a Sample Workflow Application in the Gallery of Sample Applications.

Apex 23.2 has a Workflow Monitor in the right hand task pane. 

The workflow designer has the standard element hierarchy, canvas, pallet and details, laid out with all the elements of Human Tasks and API invocation.   The diagrammer is easy to understand although it does not follow BPMN conventions,

Once a work item is launched it can be viewed in the Workflow Status Monitor.  This is a page in the sample application and is also now a template in the page create flow.  It shows the internals of the work item. 

The sample app shows examples of human tasks.  You can see examples of what a requestor might see, what an approver might see and what a task administrator might see.  These are functional pages in a simple application.  This all looks very comfortable for anyone that grew up with the Oracle Workflow product.