Does Invoking Workflows for External Projects Slow Down Runtime?

Does anyone have any input/experience/feedback on the idea of using invoke workflow to call workflows that are their own separate projects as opposed to sub-workflows that are still part of the main project?

Asking because a coworker has the habit of creating all their workflows for a given project as separate projects and then invoking them in the “main” project. Before making a fuss over it, I want to make sure I’ve done my research.

Personally, I think it’s a bad idea. It looks clunky, and if you make a change to one workflow name it won’t be updated in the main project (as opposed to the sub-workflows you can create within a project). I also imagine it might increase the runtime, but I can’t find any documentation to support this either way.

Thoughts? Is this worth making a fuss over, or am I overthinking this here?

Hi @oliviamga2!

I think that there are some points that we can argue about.

Performance

I’m not sure if it affects the performance depending on where those files are. If somehow the files that you would invoke to the main workflow are placed in a location that may need some firewall rules to be reached, this could possibly affect the performance.

Also, when you publish a project on orchestrator, you create a nuget package, so all your assemblies present in the currently project are loaded to the package. Now, I’m not an expert at all on this point, but I think, and this is just me guessing, that it may take a little extra time when execute the package if your main flow would be calling a flow outside program.

If it is true, would be this extra time meaningful to create a fuss over it? I don’t think so.

However, there are some others, and in my opinion, more important points on this.

Compliance, Securety and unnecessary work.

Suppose that you work with some version control tool, like Git, for example. Once you upload the code to repository, you will not be able to validate all the code that it is present on that project. So if you need to validate the code and put it in production, you will to guess that there is a flow not present on that repository, search for that wherever it is and validate it a part from all the rest of the code.

Besides that, once you publish to repo, you are to see every change that someone would make on that project. But, if you a have a separated flow, how would you now if something changes?

Imagine if you publish your project on production env and someone changes the separated flow. I can think in a bunch of problems that this would cause, starting from a broken robot to a harmful script executed on the robot machine.

Final conclusion

As i said, in my opinion, the performance factor is the least of your problems. If you’ll need to use the same flow in more than project, you should create a library instead. But leaving a flow where someone can access and change it, and this would affect the production env, that is something i definitely not recommend doing.

1 Like

Thank you, @Schirru, this is an excellent post with some great points. Really appreciate your taking the time to put it all together.

You’ve confirmed a lot of my concerns I had on learning of this situation, and have added some strong points in favor of keeping all the workflows for a project under the same umbrella.

Your thoughts on performance are also good to know. I was unsure whether that was even a worthwhile concern, and am relieved to know that it appears to be as you put it the least of my problems here.

I’m new to the team this is happening on, so it’s good to have some outside reassurance that the changes I am going to be proposing are impactful and important ones.

Thank you again!!

1 Like

Always happy to help, @oliviamga2!

Feel free to get in touch if you need to and best of luck on the new team.

Best regards!

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.