Share workflows between projects

I need to share some workflows between multiple projects and I can’t find any viable solution.
I have already explored some solutions which don’t fit my needs :

  • Use the “Library” system : it is just a copy/paste of the library. So the library is out of sync after the copy
  • Use a shared folder on robots : This is not an option as this folder will live outside the nupkg release versions
    What I need : some workflows that I can release in a package. A specific version of this package will be used as a dependency in projects.

We are currently storing the workflows in a shared location and the projects use the Invoke Workflow activity with the full filepath. This way, whenever an update is needed we don’t need to go edit every single project that utilizes it.

We are also storing bot information like temporary data, logs, and screenshots in this shared folder.

I think we are working on a solution that uses VSTS though where we can deploy our workflows into an environment that can’t be changed without approval. (this may or may not be better)

I believe the new 2018.3 version will solve this better with the ability to publish your shared workflow into an activity. So this will allow you to have a shared feed into studio where you can use this activity, and everytime it is updated you would simply just republish the activity again. EDIT: I do have a concern that when you update the activity that the project still needs to be re-deployed with the new version. We will have to see.

If there are better solutions, I’m interested as well.


Thanks for your reply.

The shared folder is not an option because multiple versions of a workflow are linked to it.
An example : I have a project workflow P released with version number 1.0 which uses the shared folder to invoke workflow D. If I edit P and release a 1.1 version which requires a modification on workflow D, it may break the 1.0 version (as it still links to the edited shared workflow D)

What I need : publish some shared workflows with a version number. The projects have to depends on this published package on a specific version. With this configuration I will be able to get at the same time :

  • A release P 1.1 which depends on D 2.4
  • A release P 1.0 which depends on D 2.3

So the new 2018.3 version may fit my need but only if projects have to depend on specific version of a dependency package.


It might. Here is more info: