Workflow vs Request

The purpose of this page is to explain why I love the Request feature/architecture for approval and workflow over iDempiere's built-in Workflow engine. Krishna asked an interesting question this morning during open discussion. He was implementing this workflow, and he asked the question "what if the supervisor is away?" Is there a way to specify the supervisor on the requisition itself. This question is typical when implementing workflow. What if...What if...What if... The list of special circumstances and exceptions is endless, and using a rigid workflow to model the real work is difficult to say the least. Here was the train of thought to answer Krishna's question:

This situation is one of the reasons the concept of a Role exists - to lob to a Role instead of a specific user.
In the Workflow Responsible window, you can specify a Role. Does it work? Answer: no
Dug into code:
- The Workflow Activity window that shows all work flow records. This is what shows in the Workflow Activity form you can access from the iDempiere home page when you have a workflow pending on you.
- The MWFActivity has a setResponsible(...) method that is responsible for setting the Workflow Activity => User field.
- Unfortunately neither the Workflow Activity window itself or the setResponsible(...) method has knowledge of the role.
Even if the WFActivity => Role was supported, you will still need the ability to pull it from the role and put it in your name to simulate picking it from the queue.

My comment was "the Request architecture is way better than Workflow". You get more benefit with much more freedom to simulate the real world:

You can send to a Role
The Role can pick from the queue to act on the Request themselves
If there is an issue, the approver can send it back to the person initiating the Request as many times as is needed to support the desired goal.
Requests keep a detailed log of what occurred, and it links the event back to ALL applicable objects (BP, Product, Order, Invoice, Receipt, etc...). You can add as many reference fields as you wish.
It includes email notification.
As long as your Role security is correct, the prompt for approval is natural and logical.
You can send a request from almost any window/tab.
You can send a single Request for multiple people to review, or you can send multiple Request off simultaneously in a star or parallel configuration.
You can make fields visible or processes possible pending the approval status of one or multiple active Request of specific Request Types
You can easily automate Request creation from a process
You can extend the Request process to call on external system or processes. Said another way, send the request to a computer instead of a human.
You can extend the Request to automatically pass itself or spawn a new Request to the next approver if multiple are needed.
You can tie Requests for approval to a Kanban
The list for why to use Request is so so so long...
But, the most compelling one is: It supports real world needs with little effort.