The current workflow system is mainly built on the following 2 core concepts/mechanism
conditional state transition map, i.e state machine
assign user by fixed role defined per transition
for simple business case, this workflow system is simple enough and very powerful. but a lot of improvements needed in order to handle real world workflow in a multi business unit(BU) and multi company context, like this below typical purchase requisition workflow:
Requester fill the basic requisition info,
on header, choose the responsible buyer
on item table, input item, description, qty, budget price, and select cost object
system create workflow action for all cost object owners derived from items.
cost object owner approves the request
system only complete the workflow action if not the last approval, on the other hand if the last approval, create workflow action for buyer to do sourcing
buyer input mandatory sourcing info such as vendor, price , tax etc
system create workflow action for finance manager if amount <= 5000, otherwise create workflow action for purchase manager.
finance manager approve,
if amount <=5000, request is approved/released
other further approval steps such as by purchase manager, operation manager and CFO needed if amount >5000.
To handle the above business case, at least the following improvements to the current workflow system needed
support dynamic assign users based on selected user or role from the business document other than assign users by fixed role in workflow definition
support multi user approval in parallel, e.g multi cost object owners who are linked to different items
support delegate workflow for users on leave or on business trip
support forward workflow to other colleague in case the requester selected wrong buyer, or the system assigned workflow handler decided to forward it to other person
support adding additional checker( ad hoc pre-checker) to double check, then return back to the approver
support dynamic field status per workflow state: mandatory, read only, hidden per workflow state, e.g make it mandatory to maintain sourcing info such vendor , price, tax for buyer.
support multi workflow per doctype and common workflow cross multi doctypes, for example 2 separate workflows, 1 for simple service PR(purchase Requisition) and the other for assets PR, if only one workflow, it will make it too difficult to maintain. this feature need to also support workflow revision, in other word, instead of updating existing workflow, create new workflow (new revision) to be used by new documents, on-going old documents still follow the rules defined in the already assigned old workflow.
Allow add comment for each workflow action, make comment as mandatory when Reject, also pass comment to workflow action
Send email notification to document owner when workflow reached the final state/finished.
Compared to independent professional workflow platforms, ERPNext is more powerful on handling complicated form layout design and business logic via custom script and back-end ORM, if the above features added, ERPNext can be a good alternative workflow system?
any comments and further improvement ideas? any other business workflow business cases?
Added following fields
Assign User Mode
Doc Field
User
Multi User Action Mode
Workflow Action
Added following fields
Action Source
Previous User
Actions
Workflow Field Status
Workflow
Workflow State
Field Status Detail
Workflow Field Status Detail
Doc Field
Mandatory
Read Only
Hidden
Workflow Assignment
Company
Document Type
Condition
Workflow
Delegation
Type
Delegator
Delegatee
Valid From
Valid To
Is Active
Business Logic-back end
workflow.doctype.workflow_action.workflow_action.py
create user action
check the delegation table, replace the user if valid delegation record exist
concatenate the possible actions by fields: action name, transition name and allow self approval into workflow actions field, e.g Approve:transition1:1
model.workflow.py
apply_workflow
add parameter transition_name, use transition name instead of action to locate to the correct transition
handle the 2 common actions: forward and add additional checker, complete the current workflow action, create new user action for the selected user, no transit to next state
handle multi user parallel approve, if not the last approve, simply complete the workflow action without transit to the next state
desk.form.load.py
get_docinfo : retrieve the current doc’s workflow
Business Logic - front end
form.workflow.js
show help button based on whether there is open workflow actions, even if there is no actionable workflow actions for the current user, the help button should be available for user to check the current workflow status: who is the current approver.
retrieve available open actions for the current user via get_user_actions( in stead of get_transition) to populate the action and help buttons accordingly
in show actions, add the two common buttons: forward and add additional checker
overwrite the field status per applicable workflow field status
model.workflow.js
change all relevant methods’s input parameter from doctype to doc,
form.js
change workflow relevant call parameter from doctype to doc
save.js
change workflow relevant call parameter from doctype to doc
@szufisher, this is a great idea. I believe Frappe should be able to function as a business process manager tool in its own right. Just to extend the ideas in a few of the points you’ve raised:
It should also be possible to perform the dynamic assignment of users based on a custom table so that rather than hardcoding approval amounts within the workflow definition, approval ranges and the corresponding approval users can be specified in a custom table
docfield parameter specification should use the pattern used in other areas of the app e.g. doc.items[] or doc.items[1] and should allow for python expressions for more complicated lookups
@szufisher a minor enhancement, is a feature to exempt approved notifications to all the document requestors. I.e. have the reply sent only to the creator/assigned user.
Take a case of a sales quotation/sales order, where the requesting role is Sales User.
When the document is approved/rejected, the reply is sent to all the sales users, even though they are authorized to view only their sales quotations (via Only for Creator on role permissions).
I agree. A flexable workflow mechanism will take ERPNext to a higher level as a low code development platform.
Another feature I’d like to add: Task Escalation in which a notification gets sent to a supervisor in case of task gets stalled whith no action in a specific milestone more than a prespecified number of days.
Also, I wonder about the possibility of using the de facto standard Business Process Modelling Notation (i.e. BPMN) instead of the current proprietary mechanism.
The point of BPMN is to design workflows independent of any workflow engine. It’s default output is BPEL a hideous XML/SOAP Web Services language. All BPEL engines seem to be creatures of J2EE and .NET bloat world.
Curious, I searched for “Pythonic” BPMN with RESTful APIs. The stand out seems to be SpiffWorkflow, but it is more or less abandonware.
It’s kind of weird – Python people don’t do business process management stuff?
I think one thing that limits ERPNext is its reliance on SQL relational database. The ideas of RMehta and the structure of Frappe (json) are better suited for NoSQL. Today, we do not have to be limited by a one size fits all. Maybe, it is time to look into how NoSQL can be utilized to make ideas like this topic easier to implement.
Many of these aren’t super difficult, and certainly don’t require a DB change. My company currently uses Jira for a few business workflows and ERPNext workflow engine isn’t comprehensive enough for what we do. In particular the “actions on state change” need to be more than just a single field change.
I do not care about the implementation details. I do, however care, that it’s not going to be a home grown solution in a field where years of research, experience and best practices are readily available in the open.
That would be very akin of an instance of Not Invented Here syndrom, unless there are very good reason to “home grow” a solution. (For Odoo that typically has been future licensing options at the cost of quality.)
We just have to acknowledge for once, that business workflows tend span software systems. I have never seen a comprehensive set of business workflows that can be reflected end-to-end (I mean for truely end-to-end) in a single software silo.
If you only cover parts of a workflow or parts of the comprehensive set of workflows, the solution might look exciting from the ERPNext developer’s perspective (“look what not you can do with ERPNext”), but it is almost certainly of inferior business value (even if only for lack of decoupling)
An orchestrator pattern with regards to different software stacks with a clear command and control structure and well designed workflow notation is certainly superior even for relatively simple cases, as it unlocks true operating efficiency.
Disclaimer: Out of first principles, I’m typically at war with anything that faintly smells like NIH syndrom.
Without a flexible and rich workflow , customization is often complex , specially if we need to have :
Parallel validation
Complex logic for task assignment
Reuse workflow in an other workflow (subflow)
Task reminder
Timelimit for task with task escalation ,exception management
I suspect any/all of these more complex cases and integrations can be accomplished through python scripting, and likely don’t belong in the workflow GUI anyway as they are more in the developer/superuser category. I’m more interested in a few simple improvements that would make the workflow system encompass more business use cases without going overboard. Right now you can only enter some simple validation and change a single field on state change, as well as specify the state workflow diagram. A few small additions would greatly increase the automation abilities accessible with the GUI. A little more thorough validation (or conditionals) with error messages, and more actions on state change (like clearing/changing more fields or assignments) would allow some simple automation. Clearly there is a vast amount of complexity and options that can be added here, but those can also be added with custom code.
Forgive me, but this is a strange perspective. It implies that you suggest driving a workflow out of frappe?
Except for workflows wholly englobed by the frappe framework, I think that would be a very inadequate thought model.
In my experience, end-to-end workflows tend to span several software silos, and if they are to automate human “click”-work need to keep state and talk to a lot of different interfaces, handle failures, keep audit trails, report performance, evaluate permissions, etc.
ERPNext does not come with a typical orchastrator’s boilerplate (neither a simple one nor complex one). So I don’t see why ERPNext is a good fit for sitting in that (orchestrating) driver seat. Is it?
if enough community members are still interested in this workflow feature, maybe I can consider re-open the PR for the development branch, or it can be done as an independent custom App?
