But when thinking about it from the perspective of building a microservice/custom-node, some granular control might be required to decide exactly what the sub-workflow receives.
For example, having a sub-workflow that can do multiple actions [create, update, search, delete], having these options defined on the sub-workflow trigger node level, then the user can just select the option they want from the dropdown (Similar to the ‘DropDown’ field type found in the form trigger node) instead of writing the action in a string input box.
Dropdown inputs for sub-workflows are crucial for data validity. My use case is creating subflow dropdowns so users must select valid parameters or actions. This will reduce errors and make sub-workflows more robust.
At minimum, a JSON option to define custom dropdowns in the sub-workflow configuration would be a significant improvement.
While we wait for native dropdown support on sub-workflow triggers, you can achieve the same result with almost no custom coding. Simply include an action field (e.g. “create”, “update”, etc.) in your webhook payload—this could even come from a simple dropdown in your front-end. Then, add a Switch node in your workflow (or sub-workflow) that matches on the action value to route the logic. This approach gives you clean, visual branching today without building any custom nodes.
I was looking into creating a community node, but realistically, my time is better spent on workflows than making a custom node that only a few people will use.
I already have a few front-end solutions, but a sub-workflow dropdown option would simplify things on the backend.
Once that’s in place, the next step is to allow a sub-workflow to appear in the node list and enable icon customization. I frequently use a specific sub-workflow across various workflows, so this would make it super EZ!
idea