@ankush - can you please advise if you are ware whether the ‘no-code workflows’ feat is on the Frappe roadmap anywhere, and if so, is the community able to provide some input on its development?
Another current feature that could be consolidated and proved using an automation system could be the Milestone Tracker. An automation action type could be added to create a milestone, which would give more flexibility than the current Milestone Tracker (for instance, you could create a milestone only for certain status changes using automation conditions, vs. all status changes, etc).
BTW, there’s an earlier initiative which was started here: GitHub - yashodhank/CoreFlow: Business Rules and Powered Workflows to Frappe. Development seems to have stalled. Perhaps someone would like to pick it up and port it forward?
I agree that it’s great if your team only needs to use one software. (but it would never happen because of the complexity of today’s work). However, I don’t believe your team uses automation software on a daily basis because that software operates in the background, handling necessary tasks. Setting up these workflows isn’t a continuous job, and I think it requires a different skill set, which may involve different team members.
My second consideration is how you should structure your stack and business processes. I believe ERPNext is excellent as a centralized source of truth, especially from the selling phase with inbuild or with the new Frappe CRM. However, if you’re primarily engaged in marketing activities, you might not need all that data in ERPNext, bc you want to keep your transaction data clean. Even for analysis purposes, you can integrate data from various sources using BI tools, for example.
In my opinion, it’s not a good idea to implement everything, especially when there are already excellent, ready-made solutions available. It’s better to focus on Frappe/ERPNext and leverage existing software solutions.
PS: I also use n8n and Mautic.
1 Like
I’m a core contributor on an open source python-based workflow orchestration tool called SpiffWorfklow. Several people have reached out to us recently about Frappe Integrations and I’m here doing a little research. I really don’t know if we would be a good fit for an integration or how we might compare to a tool like Mautic, but I do think we meet many of the characteristics described in this thread: low-code / citizen developer, purely python, general purpose, visual (BPMN) diagramming based. If there is interest in working together to integrate SpiffWorkflow into the Frappe Framework, I’d be down talking to folks about it.
5 Likes
I would definitely vote for integration of SpiffWorkflow and Frappe, especially with both being open source and offering a self-hosting solution.
Maybe someone from Team Frappe could join this discussion?
1 Like
I certainly have no objections to a SpiffWorkflow integration (though I’ve never used it). That doesn’t really solve the problem of: it’s another system that the business has to maintain.
If it would be feasible to include automation workflows in ERPNext/Frappe, I think that would be huge.
2 Likes
There is a core SpiffWorkflow library - GitHub - sartography/SpiffWorkflow: A powerful workflow engine implemented in pure Python - pure python with only one dependency on lxml, that could be integrated into anything and can execute BPMN workflow diagrams. - You would need our BPMN IO modeler extensions added to the frappe UI so users could draw out their workflows. - you would need to re-implement all the storage, file management, testing framework, reporting that comprise our complete application, but the pieces are there if you wanted to tightly integrate the library into Frappe.
2 Likes
I’m in agreement with @oguruma. There’s already a Frappe graphical workflow builder, milestone tracker, notification module, etc. Expanding and/or eventually replacing these with a more flexible and comprehensive automation toolkit that works natively with the Frappe framework doctype model would seem a preferable strategy vs. trying to integrate with 3rd party apps (over whose strategy/direction the Frappe development team wouldn’t have any control).
I would love to see a BPMN compliant workflow engine incorporated into Frappe.
BPMN is an open standard (https://www.omg.org/bpmn/) and the de facto foundation for most enterprise strength process automation tools.
This idea has been discussed many times on this forum:
My organisation started off using Camunda, then migrated all elementary workflows to N8N, and recently transferred most of the remaining Camunda processes to Spiff. Spiff is not as yet a complete replacement for Camunda, but suffice in most scenarios. We use the open source bpmn.io modeller and then execute the models on Spiff.
It would be a god-send to incorporate the bpmn.io modeller into Frappe / ERPNext and bundle the Spiff engine into Frappe.
1 Like
Hi @EugeneP:
Right now, @buildwithhussain cooking this live (5th episode of the series …)
Hope this helps!
1 Like
The biggest “drawback” with regard to the current Workflow capability in Frappe is that it is in essence a State Transitioning tool, not a fully fledged process automation tool.
In other words, I can influence how a DocType’s status changes but I cannot model a complete business process at a very high level in an organisation. I refer to this level of abstraction as “top ware”. It should exist without assigning any specific software or human participant to the process’ constituent tasks. This level of abstraction then allows you to choose your systems dependent on the process, and not the other way around.
There are many other aspects which comes with a BPMN capable solution such as human participant delegation and escalation, which is not possible with the current Workflow. Many of these considerations were discussed in the above referenced topic.
6 Likes
May I take the liberty to suggest a few ideas.
I (actually we) am not a developer. We are best described as hackers who can cobble together a few scripts, but to participate in developing such a feature is completely beyond our capabilities.
Having said that, we can certainly assist with insights and our current work-around we use to incorporate BPMN.
I think @danfunk is the most critical resource we could hope for. He’s the one who will be able to determine the nature of the 2 main components and their integration into Frappe (at least as seen from my non-technical perspective):
1 The BPMN modeller. Spiff uses a customised version of bpmn.io so that the models are embellished with sufficient metadata in order to execute on Spiff. bpmn.io is a JS library which can be rendered in any Desk view just as Frappe incorporates the Ace editor to edit HTML / JS / Python etc.
2 The Spiff engine itself is a Python module / library with a single dependency namely lxml. So it should be no effort at all to bundle the engine with Frappe.
The biggest amount of effort will be to amend the Frappe database structures and the ORM abstraction layer to accommodate this feature. The modeller would have to have access to the ORM layer so users can select an object on the modelling canvas. And likewise the engine would have to update the site’s DB over and above maintaining it’s own data structures. Please advise whether I’m smoking my socks…
1 Like
If you don’t mind me asking, what is the actual process that BPMN uses to execute the programmed actions?
I started toying around with a custom app using a similar approach to Mautic (only because that’s the closest application to this that I am familiar with).
Mautic basically creates a row in a table and then uses the cron to loop through that execute each action. The system admin has to manually configure the cron jobs (it doesn’t have a scheduler like Frappe), and Mautic recommends having the cron run every 5-10 mins.
Since every workflow action has to be looped through once that cron runs, it can create some scalability issues if there are a lot of records. Unfortunately, I don’t have clients big enough for that to be a concern, though 
taking steps: feat: flow tracing by blaggacao · Pull Request #27944 · frappe/frappe · GitHub
At this stage, only in-depth technical feedback please on the PR.