delete flow variable

Maybe I ask the opposite question. Why is it necessary to delete flow variables? Honestly I never had the feeling I need to delete them. They are just there.


If you don't like them, you could also put the functionality inside a wrapped node. Flow variables created inside a wrapped node are not available outside of the node (if you don't want them to be)


I use a wrapped node, which protects the scope of any flow variables within it, and use quickform nodes to provide configuration options. These allows for parameters and selections of input table values. 

I have found that with this any corruption of flow variable from different parts of the workflows can be prevented. I also use call local workflow node to create factories so I can have a generic workflow that passes control to local workflows to deal with anything specific. This keeps the scope of the flow variables precise to where it is needed. 



It is not strictly necessary to delete them. But it would be nice if that were possible.

I am working on a fairly large workflow and there are many variables that are only specific to certain parts of the workflow but they still show up in the setup for nodes that are further downstream.

Certainly, wrapped nodes/metanodes can help, but they don't always provide what I want. Sometimes I want to export a specific variable from a metanode while discarding all other variables. I don't think this currently possible.

For me it is mostly an issue of having a clean workspace while still being able to express myself with any variables that I would need to describe what I want to influence. In most programming languages you also have local and global variables that you can use to give names to intermediate or permanent values. And the local variables are always gone after a function returns.


Hi, it could be necessary in some situations. For example, if I use the extract context properties node, it creates incompatibility with the Python nodes that throw the error "Requested string value from cell with type: STRING".

So if I use the David Ko trick wrapping the extract context properties and keep only the variable I need from context and rename it the error disapear.


I have the same problem merging two different workflow I have problem with flow variable with the same name, a node that permits to delete or rename a folw variable it will be very usefull

Hey @Iris,

I try having a more canonical view on that:
A variable is defined by a name, a type and a visibility. “name” is the unique identifier within the “visibility”. “type” defines the range of valid values and allowed operations. “visibility” tells something about who is allowed to read/modify a variable (realm).

A variable from a realm may under no circumstances be accessible from another realm (security) - else wise the value is no more trustworthy and/or a security leak may arise.

From that point of view, a kind of “garbage collection” or “limited visibility” makes sense!

@aborthwick: A common approach to circumvent these situations is by using realm-bound prefixes (e.g., variables used during data load are prefixed “dl” while variable used within processing are prefixed “pc”).

Kind regards,


Hi @Iris,
I would use wrapped metanodes for encapsulation flow variables.
But, there is one usecase, which prevents using wrapped metanodes:
I have hundreds of interactions with databases and I can’t using database nodes within wrapped metanodes, if I want to start my workflow as a scheduled workflow on knime server.
The reason is, that I can not get the workflow-credentials into the wrapped metanode! The only way to do this, is to use quickforms for setting username/password. But this won’t work with scheduling…
So I have to deal with all flow variables along the complete workflow…

Another thing is: I created some generic Nodes for our organisation which contains database-stuff. But with wrapped Metanodes we cannot use these (see above). And so, all colleges get flow-variables they won’t have…

1 Like

I absolutely agree with the convenience of having a Variable Filter node.


Hello @mpenalver,

your request has been noted. (Internal Reference: AP-16515)



The inability to filter flow variables really causes hassles in creating large workflows that have duplicate process components or node collections. It builds up a massive confusing backlog of flow variable clutter, it causes duplication of flow variables when reading and writing variables to memory, and in general it is just bad practice to leave a confusing mess of “single process use” flow variables in the larger workflow pool at risk of being used in error on a later date… I don’t get why anyone wouldn’t want the ability to filter variables? Is this still not possible?


I guess only “remove them completely” for parts of the workflow by using a component

1 Like

Components not passing flow variables does help, but the flow variables in a workflow that control large numbers of components can’t be wrapped in components…

This must be a relevant issue for a lot of users considering that it has 2800 views. :wink:

1 Like

Hello @iCFO,

Nop. Have added +1 to existing ticket mentioned above.

Although number of views is relevant topic is pretty old so might be a bit misleading…


1 Like

I’m working with a workflow where a Variable Filter would result very handy.

Please add +1 to Internal Reference: AP-16515



+1 added! This is a very popular request, no doubt. :slight_smile:

1 Like

Hi @ScottF ,

From my side and regarding the issue with ‘overwrite Path Variable’ , as mentioned in the topic:
“All these workarounds could be avoided with the implementation of an ‘Overwrite Variable’ function within the ‘String to Path (Variable)’ node.”

An alternative option could be to release a node update with an ‘Overwrite Variable’ option, as it is included in ‘Java Edit Variable (simple)’ node, see picture . It would avoid some workarounds.


I’m also interested in a Variable Filter Node.


Hi @k_n_i_m_e_r (and others) -

We have a thread on the #feedback category about this very issue. Please be sure to cast a vote in the thread if this feature is a useful one to you:

1 Like