I see that this feature was already requested in 2020 for the Old UI, but would it not be fantastic if a user could enable/disable (groups of) nodes from executing: either by way of a simple right-click → “Disable Node” and/or by means of a boolean parameter/variable. So, for example, envision being able to set the variable “write_to_database” to False: all (meta-)nodes that use that variable are all disabled, maybe in 10 totally different places in your project.
Disabling a metanode should also disable all nodes within it.
Hi @sambadancer 
I’ve suggested similar before
This feature is already implemented. You can achieve this by using the if /case switch nodes and stop certain workflow branches from being executed.
Have a look at example workflows featuring these nodes:
Hi @HaveF,
Ah, thanks! I search for “disable” instead of “bypass” 
Hi @Add94, that’s cool! Certainly going to try that out!!
thank you so much!
1 Like
I certainly was thinking about doing this via case switch / if set up as well… still means that if there are 10 nodes you want to deactivate you either need to connect them all to the same flow variable port from Case Switch Start or have a separate Case Switch Start “near them” (thinking about 10 DB writer nodes nested into different meta nodes here…)
I like the idea of finding an easier way to do this…
4 Likes
Interesting, would you have an example workflow to share demonstrating this challenge? I was thinking to simply add db input/output ports to a single case switch nodes (as many as you like) and have 10 independent branches being triggered based on a condition. But then I agree it depends on how the trigger condition is defined and the setup may be more complicated because of that.
Maybe the whole idea of passing variables on in the workflow like it is implemented now, has its limitations.
Not (at all !!!) wanting to denegrade KNIME, but I know of another tool (Data360 Analyze and its predecessor Lavastorm Analytics), which has this functionality implemented in another way, which is extremely practical and flexible:
Parameters can be created at the “Graph” level (= Workflow-level), at the “Composite”-level (= Metanode-level) and at the “Node”-level. You can already see the hierarchy: A parameter at the higher level is valid for all lower levels, unless explicitly overruled at that lower level.
No lines necessary, so no chance at spaghetti.
Note: parameters could, for example, be one of the following types: boolean, choice, password or string.
The “boolean” parameter type could then be used to enable/disable (meta-)nodes: These all have the option “Enabled”, with 3 possible values:
- Enabled (default)
- Disabled (manually, by right-click the node and choose “Disable”)
- Other, with the value of the boolean parameter.
The last option is especially powerful if you can combine multiple boolean parameters with AND and OR!
Note: We build extremely complex analytical routines, sometimes with 30.000+ nodes, so you could imagine that sometimes, you would want to enable/disable specific parts of the routine, such as all 200+ places where a DB Insert is performed when you only want to test your new functionality except that part.
Note 2: The tools I mentioned above are “dead”: Lavastorm once was seen as THE main competitor the Alteryx, but its successor Analyze is somewhat of a failed project. Lavastorm had its unique features, though, and KNIME could really be an Alteryx killer if it implemented these.
1 Like
Let me see if I find some time to create an example…
1 Like