At present, nesting workflows is an arduous process. In order to create more complex workflows, it’s necessary to use Execute Workflow node. However, this turns the workflow into a black box, which makes testing very annoying and time consuming.
I have found many different past posts where people have looked for drill-down and they didn’t get much attention, so I have made this official feature request to put it on the radar.
Requested features
To make nested workflows easier to manage, I suggest the following features:
Ability to double click a sub-workflow node to open that workflow (drill-down)
Ability to view the sub-workflow’s progress by double clicking the workflow node while it is executing
Ability to view where the sub-workflow stopped on error without clicking through to the ‘past executions’ page manually
I think it would be beneficial to add this because:
It would make development and testing of hierarchical workflows much more efficient. It would empower the user with more abstraction and allow for much more powerful workflows.
I like the original Idea of being able to go to a subflow by clicking on the execute workflow node.
But now you are adding some extra stuff that is not easy to implement at all.
I understand that it can be very helpful to have these features and I do like the idea, but you are stating: “wouldn’t require too much additional code”, this is just wrong I think.
Of course you can prove me wrong by submitting the code to implement this in a PR
shortcuts for gouping nodes int oa subworkflow are a pretty interesting idea which in theory could even be done with a browser script.
ungrouping could potentialy be pretty dangerous if that subworkflow is used in other workflows. In this ase CRTL + Z for undoing the grouping would probably be a safer option as it only works for a limited time ater grouping.
All in all a cool idea, I am really eager on seeing future updates to the “Execute workflow” node with all those ideas floating around in the forum
What I was going for was the minimal feature set to make grouping work and that requires least restructuring to the code, because this feature has been requested for 3 years and no one has done it, so I’m trying to spur discussion about it. In fact my intention is not to add ‘extra stuff’, but to make the problem as simple as possible.
Which part of the above is what you considered difficult? Maybe there is a more elegant solution.
Double clicking the subflow to jump to that workflow is certainly the simplest feature, but that alone doesn’t solve the problem and isn’t very useful.
this feature request is not that old, so maybe it is best to add this discussion in the feature request that is 3 years old. I know there is a couple that contain features that touch the execute workflow node and to add useful stuff.
The thing you suggested here is a lot more involved, yes you describe it well, but it is far from easy/fast to implement, which is what you suggest by saying it doesnt require much additional code.
I do agree more features like this would benefit n8n and the use of sub workflows. But your statement is simply wrong, and maybe not the right place as your feature request here is fairly nice and easy for the team to implement. So if we start complicating that with the discussion of more advanced features, then it might lose focus on this feature request is about.
My original post seemed to be a lot more involved (drilling down mid-execution to view the progress of the workflow). And seems like it would be something that would be done after basic node grouping (the feature in the linked post). But I agree that these are two different things, and will move that reply to the other forum post.
Yes you are right, that bit is. But the other bits of just opening a subworkflow aren’t
And depending on how it is tracked under the hood, it might actually be fairly straightforward to also drill down while executions are happening, as they are visible in the executions. Just need to find the right URL to get to it.
PS. node grouping is something I never liked. We have subworkflows for that. So some ideas like node grouping are just a bit weird in my opinion. But of course making it easier to create a subworkflow with an exisiting workflow like you suggested is a nice idea.
