TeamSpace Best Practices

Hi everyone :)

I work in a small team of three, currently using KNIME Desktop. To share workflows, we have a process where we export the workflow to a ZIP file and commit that to our version control repository. The problem with that is that we can’t really see exactly what the changes are someone made, and the workflows aren’t really portable to other Desktop installations, if someone hard codes a path to the data files, for instance.

We recently purchased KNIME TeamSpace; how would we best use TeamSpace to share our workflows, so any one of us can make changes, and the others can use them? Are there any other practices you recommend we adopt?


-- Patrick

Hi Patrick, 

I guess the main challenge is sharing data files between different users?  If that is the case, have you tried copying data files to the Teamspace mount id and using either mountpoint relative or workflow relative URLs to referece the files in your reader nodes? 

You can now user URLs like:

- relative to the current workflow 


– relative to the workflow‘s mountpoint

Does that help? Are you running into any other challenges? 

Best regards,



I've seen this URL format before & wanted to try it out -- where's this documented more extensively for non-developers?



Thanks for the reply :).

Our main concern is sharing the workflows between different users. We will each have our own set of data files, but need to execute the same workflow against them. When one of us has to change the workflow, to fix a bug or add new processing nodes, we want to make it easy for the others to pick up those changes without them having to manually change their workflows.

-- Patrick

Hi Patrick,

since the team space does not (yet) provide a mechanism for version control, I would avoid having different users perform concurrent changes - in particular for complex workflows. In our environment, we usually try to define one "owner" for each essential workflow. That person is responsible for collecting and incorporating changes and "curating" the workflow.

Previously, we had examples where one user fixed a "bug" (that was intended behaviour), which caused problems with other use cases. If your workflows are complex (and their complexity usually grows over time), it can be really difficult to assess all the consequences of a modification if you don't know the details of a workflow.

Hope this helps,