Share workflows between projects

[dev_partnaire_sca]

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.

[ClaytonM]

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.

Regards.

[dev_partnaire_sca]

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.

Regards.

[ClaytonM]

@dev_partnaire_sca

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:

#FeatureBlog - 18.3 - Library (Reusable components)

First, big thanks to @mircea who has helped put this in place. Today’s topic: Library (Reusable components). What is it? A Library is a collection of reusable components. A reusable component is a workflow that can be compiled and packaged as an activity and reused in multiple processes. So go ahead and define all that common code once and reuse it multiple times. You can now create these workflows and publish them as activities. Why do you need this? Reuse is a key enabler for improving bu…

#FeatureBlog - 18.3 - Publishing improvement

Hi there! Let’s cover another new improvement in the life of RPA devs. Today’s topic: proper publishing capabilities. Remember the Publish button that would just automagically publish your process somewhere. You weren’t sure if it was on the Orchestrator or local folder or how did it come to the new version number. Now everything is much more transparent, but let’s start with the beginning: [image] The publish button was moved in the Design ribbon, where it is a better fit for it. Let’s move…