Hi, friends!
I’m new in this community. First of all, I would like to say that I am impressed with the possibilities that n8n provides and what your team creates.
Forgive me if this idea has already been discussed before. I also want to apologize for my English. Google translator doesn’t always understand what I really want to say 
Prerequisites.
When developing large and complex scenarios, there is often a need to isolate part of the repetitive algorithms into separate functions. And also be able to change the logic of the algorithm in one place, instead of changing it in all workflows using similar logic.
I have found several ways to do this.
1. Use the “Execute Workflow” node
Pros:
+It’s easy to use when the number of such workflows is small
+It works.
Cons:
-Difficult to use with a large number workflow-functions. You need to remember what ID you need, remember how it works, what data is required for entry. To prepare this data, you usually need an additional “Set” or “Function” node.
-A workflow using a large number of “Execute Workflow” nodes becomes unreadable. It is not clear what node #37 or node #45 (for example) does, the general logic becomes non-obvious.
-Difficult to debug
2. Use the “Webhook” node
Has the same pros and cons as “Execute Workflow” node. But it makes debugging easier. You can run the webhook in idle mode and get productive debugging data. On the other hand, it is less secure and less performance.
3. Use the “Function” node
I can define custom classes and functions and use them to isolate repetitive logic. Unfortunately, this is no longer quite low code and this approach is not available to all users. In addition, I discovered that it is impossible to define and debug global classes and functions in real time. This requires setting up a docker installation and restarting n8n. This negates the benefits of this approach.
4. Create custom node.
Pros:
+Easy to manage and use
+Workflows using native nodes are easy to read and understand (unlike “Execute workflow” nodes)
Cons:
-creating a custom node is a difficult and time-consuming procedure. It pays off only if you plan to use custom node hundreds or thousands of times in workflows. For most of my tasks, this path is not suitable. I don’t think that is not suitable just for me.
Idea.
I propose to add the ability to create custom nodes based on workflows in order to combine the Pros of approaches 1 (“Execute Workflow” node) and 4 (Create a custom node).
Suggested changes:
1. In the “Start” node of each Workflow, add the field “Custom node” of the boolean type. All workflows with this flag appear in the list of nodes and can be added to any workflow as a regular node. They will work similarly to the “Execute Workflow” node, but with minor changes (described below).
2. In the “Start” node of each workflow add a button to upload “custom node icon” (visible only if checkbox 1 is checked). In the node list, this workflow will be displayed with this icon.
3. In the “Start” node of each workflow, add the following fields (visible only if checkbox 1 is checked):
-Node name. In the list of nodes, this workflow will be displayed with the specified name
-Node description. In the list of nodes, this workflow will be displayed with the specified description
4. In the “Start” node of each workflow, add the ability to add and remove custom “node settings” fields. For each parameter, a type, mandatory filling, description can be specified. For starters, the Text, Number and JSON types will suffice.
These parameters will be displayed as input fields for custom node. Similar to how the node settings are now implemented, but a little simpler.
5. It would be great (but not necessary) to add the ability to debug custom nodes created based on workflows, as this can be done when debugging webhooks. Launch a node to wait for a call. Catch and display the result of the first call to the custom node.
6 It is desirable to add a field of “Start” node to specify the custom node location directory. This will make it possible to quickly find the required custom nodes in the general list.
I think this feature will give really impressive possibilities for writing large and complex low code workflows.