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.
2 Likes
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. 
3 Likes
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?
1 Like
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?
4 Likes
IMHO, Frappe is actually an orchestrator that can instantly deploy modules (like microservices in the container world of docker and kubernetes) after the schema is defined under developer mode.
1 Like
Workflow across doctype is a need and frappe needs such feature. I think this should be part of core.
1 Like
I also agree that ERPNext should have a more feature rich workflow capability.
The current workflow capability lacks things such as:
- Better modeling of real-world process flows, rather than the state transition tables currently in ERPNext
- Delegation and escalation of a specific “task” to an individual user, rather than the current role based allocation rules
We use the Camunda Modeler to design our process flows : Camunda Modeler - Design Business Processes and Decision Models
This modeler is written in JS and is opensource, hence incorporating it into ERPNext should not be too difficult. It’s a JS library and it can be customized to contain only the most basic modeling features :
bpmn-js walkthrough | Toolkits | bpmn.io and also GitHub - camunda/camunda-modeler: An integrated modeling solution for BPMN, DMN and Forms based on bpmn.io.
We also use Camunda as our process engine, with integration via the APIs in both Camunda and ERPNext. We do not integrate any other system other than ERPNext and find it’s unfortunate that we have to break out of ERPNext in order to manage rather simple process flows.
Camunda Modeler : Download The Camunda BPMN / DMN Process Modeler | Camunda
Camunda Engine : Download Camunda Platform 7 Community Edition
6 Likes
No not necessarily. If you have complex requirements you could drive state changes using the API from an external orchestrator. Likewise, code can run on workflow changes in frappe with the current system and do anything you like (such as call external software etc).
Right now I’m mostly interested in some very BASIC things that would allow us (and by us I mean ME) to implement some simple non-automated workflows just in frappe through the UI. There are a handful of things that I think would make what is there now dramatically more useful. I attempted to reimplement some of our Jira based workflows (which are NOT complex) in ERPNext and couldn’t. Notably there doesn’t seem to be a way to communicate validation on state changes (ie to report to user “field X must be Y”), or do any actions on state change other than setting a single field value. If those were improved it would at least meet MY requirements. Not attempting to claim MY requirements are everyone’s!
1 Like
If adding features also means providing a documented escape hatch out of those features amd into a rock solid workflow solution, that can be acceptable.
Since every code/feature is a legacy, not documenting and fulky supportinh the escape hatch might be a dangerous path. If a full blown integration wiith camunda/zeebe is documented (maybe even integrate the modeler as @EugenP suggested) it will become a lot easier for maintainers and the broader community to not fall into the falsehoods of feature creep.
I don’t really see this as an either/or question. Frappe’s design philosophy has always tried to maximize both internal power and external integration.
To that end @blaggacao, no escape hatch is needed. The way to bypass frappe’s workflow mechanism is to never set it up. I don’t know much about Zeebe implementation requirements, but given the scope of Frappe’s document API I have to imagine that linking an external orchestrator would be both possible now and relatively straight forward.
Precisely to avoid feature creep, the Frappe maintainers have lately been encouraging integrations as separate apps, maintained by the community. You seem passionate and knowledgable about Zeebe, which makes you the perfect person to get that work going!
2 Likes
Well, that sounds nice to fend off my activist vocalism, but it does not really solve the problem at hand:
Firstly, I’m a singleton. So I would never dare to seriously offer to the public a half baked, unsupported dependency for them to build a business critical workflow engine on top.
We need a blessed and officially supported pathway to workflow managament.
This thread suggests mainly two lines of thought:
- build on the shoulders of giants (nanos gigantium humeris insidentes)
- build something “quick and easy” within the community’s comfort zone (= python/frappe)
Disclaimer: I’m not only a fierce adversary of NIH syndrom, but I also don’t have much sympathy for comfort zones as they tend to produce suboptimal outcomes. 
So in the case that upstream maintainers want to exploit the powers of workflow managament for their open source erp suite, and only in that case, they have to decide between those two lines of thought.
As I said, we have to acknowledge that every line of code written is a (huge) legacy. If we take a closer look this is true for the second option (home grown solution) in even more than one direction:
- Maintenance of the code itself
- Improve the thought model behind the implementation: a feature is always also a promise to the users.
Having far less dedicated resources than the camunda community, the second point is going to be a constant catch-up game for which the erpnext community probably lacks resources to spare.
I’m actually pretty confident that the upstream maintainers will have the wisdom to make the right choice here (as they did by incoportating java based QZ Tray for host device access). As we can see from this thread, a demand for a solution seems to exist.
2 Likes
I’m not deflecting your activism. I’m suggesting that this…
…is a false and unproductive dichotomy.
Frappe is full of features that are implemented faster/better/stronger elsewhere. That doesn’t make them bad features. Frappe’s public-facing cms framework doesn’t come close to Drupal or Jamstack, for example, but it is nevertheless extremely useful to those whose needs are simple and who don’t want to manage a whole separate technology stack. For somebody who just wants to define a leave approval process, likewise, telling them that they need to load up a complex third-party orchestration platform is not a great answer.
Zeebe looks great. The next step, however, is not activism. The next step is a proof of concept. Frappe already has all the hooks you need, and I strongly suspect that little to nothing in the core code will need to change to make the integration possible. There’s no need to wait for a blessing.
3 Likes
Zeebe may look good. But have a look at the license:
Condition 2: Without limiting other conditions in this Agreement, the grant of rights under this Agreement does not include the right to provide a Commercial Process Automation Service.
A “Commercial Process Automation Service” is a service intended for or directed towards commercial advantage or monetary compensation for the provider of the service enabling third parties (other than the provider’s employees or Contractors) to deploy and execute Custom Processes or to access the Software via its APIs.
By just quickly reading, I would understand that no commercial support may be provided to clients by Frappe Consultants based on Zeebe, since they would provide a “service directed towards … monetary compensation” “enabling third parties [the customers of the consultant] to deploy and execute Custom Processes…”
Maybe I am wrong, but this should be considered first…
1 Like
Looks like somebody already started with n8n:
Their license says:
Without limiting other conditions in the License, the grant of rights under the License will not include, and the License does not grant to you, the right to Sell the Software.
For purposes of the foregoing, “Sell” means practicing any or all of the rights granted to you under the License to provide to third parties, for a fee or other consideration (including without limitation fees for hosting or consulting/ support services related to the Software), a product or service whose value derives, entirely or substantially, from the functionality of the Software. Any license notice or attribution required by the License must also include this Commons Clause License Condition notice.
In the case of Frappe/ERPnext I would suggest that the value of the product or service DOES NOT derive entirely or substantially, from the functionality of the Software (N8N).
1 Like
Both n8n and zeebe seem.to operate under the faircode.io philosophy. (btw that’s a marketing invention of the creator of n8n)
However n8n seems quite a lot more restrictive than zeebe.
“Service” in “Commercial Process Automation Service” coincides with kubernetes’s usage of the term, as long as it is commercial (either public or private). This clause is meant to fend off big money competition against their own SaaS offering.
n8n is quite a bit more restrictive, which generally prohibits making money with their software.
And if workflow management is part of the requirements, that is has an identifiable price tag, then it is definitively of substatial value to the product or service offering (of an independent integrator).
n8n does compete in simplicity, though, while zeebe competes on industry standards: BPMN 2.0 — a slightly more concerted (much more than) marketing initative from the founders of camunda, among others.
It is hard to say who is the right go-to partner community for the ERPnext community.
Standards have certain appeal and conduct implicit long term guarantees, though.
1 Like
Since time constraints on my end are not a shameful circumstance, I’m still actually looking into the option for somebody to step up. Sure, I would prefer to upstream the investment and put it at the source rather than a local and siloed reverberation of the cause with little long term upside potential.
Done that in the past. It’s utterly frustrating to my vision’s aspirations.
1 Like
Have you had a look at this:
https://netflix.github.io/conductor/
Comming from Netflix under apache license.
1 Like