I used to be able to use the Invoke Workflow activity to reuse processes and when I would update the process, all the workflows that invoked that process would immediately use the updated process.
I’m not clear on why this changed since the whole process of creating reusable components through a library is 100x more complicated and time consuming: creating a library, configuring the settings, publishing the workflows, adding dependencies through manage packages, adding the activities, and then… if you update the process, going back to each process that utilizes that workflow and updating the packages whenever the slightest change is needed.
So far, this is completely useless since it is much easier to copy and paste the workflow into each process to update it rather than going through the whole Libraries feature. Although that is still more of a hassle than the Invoke Workflow was.
My question: is there any other way to Invoke Workflows that aren’t in the same project folder?
If your project is Windows project, InvokeWorkflowFile activity doesn’t support to call xaml file outside the project folder. If so, can you try to call it under the project folder OR use Windows-Legacy project.
Creation of library would be a one time activity if you make it robust…
Yes there is some hassle while creating but in any scenario where you have to get reusability you have to make it as a separate library only and needs to be published and should be updated when a nee version comes in
On the other hand down side of copy paste it …you have to replicate changes in every code which is not a standard procedure too…also while copy pasting the xamls there are high chances few project dependencies might conflict which is an issue again
I agree with you that if there is a way to upgrade the libraries in all processes at once would be a good feature…currently there is no direct way…It is already shared as a feedback and hope we get it
One way is this using libraries and upgrade dependencies
Thank you, I agree being able to mass update dependencies is sorely needed.
The Invoke Workflow activity used to be so much easier and more effective than libraries. It’s just hard for me to understand why anyone felt the need to overcomplicate things.
You can create the library and publish it as a package.
In any project you can install the package from the manage packages.
This workflow you can use in any project in UiPath studio.
The library option is visible when you open the UiPath studio. In right side you find the process, library, state machines.
In that select the library create your workflow. Publish it as package.
Library is a reusable component this can use in any project which decreases the time of developing the repeated workflows.
Why? Unless they need the new version of the library, because they need the new features or a fix, there’s zero reason to update all your other processes that use the library.
Really? I’m looking for a simpler way to use reuse processes. Libraries are nowhere near as easy as the invoke workflow and I don’t get why they took away the ability to reference a workflow that isn’t in the same folder.
not agreed on this statement, as there are pros and cons as well
an argument, that can also be critized by the opposite viewpoint in other scenarios
a technique is to externalize common shared xamls in separate projects and include it within the consuming projects via symbolic links. So it looks for the consuming project as locally stored, but grace to the symbolic link we don’t have duplicated xamls. Also when editing the linked xaml it is directly edited on the linked location itself
That’s a very interesting suggestion. Sounds like you’re saying create a shortcut within the folder so you can still use Invoke Workflow as if it were local, but when you make changes, they will automatically propagate to all workflows. I’ll have to give it a try.
I’m not sure what the argument would be for the usefulness of libraries over the original ‘Invoke Workflow’ activity. I’ve watched youtube videos on creating libraries and a good one takes 30 min to explain, while using the Invoke Workflow activity would take 20 seconds to explain well. Just doesn’t make sense to me, but I guess I’m the only one who thinks a 3 step process that auto-updates shouldn’t be made into a 50 step process that requires 20 steps to update for each project that uses it.
No @postwick I didn’t search from any website or chat gpt.
I have given the answer on my own basis. I just told to how to create the libraries and how install to those library packages to reuse in the studio. This libraries we usually use for reusability and for saving time. I have included those points only.
Can you give an example of what you mean when you say reuse processes? What kind of process do you mean?
Libraries are for building activities. Examples of the activities I’ve built into libraries:
Find previous or next business day
Log into an app (we have libraries for different apps)
Check a spreadsheet to see if the current time is within a downtime time range
Submit an item to a logging automation (ie insert a queue item)
These are basic single steps. Activities. I wouldn’t call them processes, which is why I’m asking what you mean by processes.
Sometimes we will add features to an activity, or add activities to a library, but we haven’t yet needed to go back and update the library version in existing projects because they are already working with the existing version of the library/activity.
One of the most common processes I use involves uploading documents to my electronic medical record system. I have several other automations that result in the creation of a document like a copy of an email, a record pulled from another source (medications, labs, etc.), or a billing statement. Each of these needs to be uploaded to the EMR.
I’ve used Invoke Workflow for this for years because I’m able to drop in that activity, point it to the .xaml, and import the arguments to pass into it (filepath, date, time, doctor, etc.). Done.
Every few months, the EMR changes something about the process that causes it to fail, so I need to make a minor adjustment to get all the processes back on track. It would take only a couple min to correct the source process and all the related automations would immediately start functioning again.
When I’ve had something simple that I just need to drop into an automation that won’t need to change, like the examples you mentioned, I just use a snippet, quick and easy.
This sounds like more than what libraries are intended for. It sounds like you should publish the “EMR upload” process as its own automation, and then other automations can submit items to a queue that the “EMR upload” automation pulls from.
It seems like there isn’t anything as easy and effective as Invoke Workflow. That’s disappointing. I just wish that option wasn’t taken away for the new Enterprise version.
Quick example - a developer builds a XAML which logs into a web portal, that login XAML is included in a ‘reusable components’ library which is then published to Orchestrator. You have 10 processes which all need to log into that web portal, but one day the third-party changes the login page and all ten processes break.
If you had to copy and paste XAMLs between projects, that’s ten change requests, ten code branches, ten tests, ten approvals/pull requests, ten merges, ten new packages to deploy.
With libraries, a developer can fix and test it once. At that point it’s tested, approved, and live code, so it can be handed it off to the support team to update the package in the other nine processes without necessarily requiring extra approvals or effort on the developer’s part.
If you are working across multiple environments and Orchestrators, once the library has been published once, it can be uploaded to the others quickly and easily. It also allows you to build CI/CD pipelines to deploy that new library package automatically.
Based on your question, I’m assuming you’re not using the object repository, as the OR is enough argument for using libraries by itself.
It seems like libraries would be helpful in situations where you have multiple people working on different aspects of projects and a support team to deploy.
It remains much more convoluted than the ‘Invoke Workflow’ activity from another folder that is being retired. It’s just a shame.
Thanks for your input!
Anil_G
mukesh.singh
postwick
anjani_priya
Anelisa_Bolosha1