Replace Invoke code by invoking Coded Workflows inside your project


I am sure many of you are fond of the Invoke Code activity, especially in situations when you just have to do something so specific that it is much easier to type it out than to use one of the default activities. I get it :slight_smile:

This is why I want to point you towards the Coded Workflow file in the latest Studio. Creating one is super easy, and you end up with a nice blank canvas:

Now that you have seen it, you have to ask yourself a simple question…

…should I ditch the Invoke Code for a Coded Workflow?

Well, it is of course entirely up to you. However, I’d like to showcase how easy it is to work with a Coded Workflow in the latest Studio. I will do it on an example of a cross-platform project, but it is of course available on Windows projects as well.

In our small example, we will do something that is currently not possible with a standard set of activities. We will make an HTTP Request with a binary body input, which in our case will be a sample Excel file.

In fact, you can see that the only package installed in the project is the UiPath.System.Activities one; there is no need for the WebAPI package at all.

Step 1 - Create your Coded Workflow .cs file

As mentioned above, you can simply go to New → Coded Workflow and quickly create one. It must be a Coded Workflow, which is important in the next step.

Step 2 - Add the Invoke Workflow File activity to your Main.xaml

In the next step, we will immediately try it out by simply invoking the Coded Workflow as is from another XAML file.

Step 3 - Try to add a single input string to your Coded Workflow

To see how easy it is to pass arguments between your Invoked Coded Workflow and the Main.xaml, try adding input and output arguments in your Coded Workflow and see what happens when you save the file.

Here is a small video how this works for one single argument:

And here you can see how it works for a single as well as multiple output arguments:

Step 4 - Write more code into your coded workflow file

Don’t just use ChatGPT to give you the code like may be the case in this tutorial :sweat_smile:

Step 5 - Configure your inputs and outputs and run your code!

You have now successfully invoked your Coded Workflow .cs file from inside of your Main.xaml. Congratulations!

Project files for those who want to “dig in” (10.0 KB)

What do you think? Will you ditch the Invoke Code?

Is the Coded Workflow file a bit too verbose when you want to run a single line of code? Probably yes. But it is surely worth giving it a try, especially given how much easier it is to write longer snippets of code in a separate file with all the extra features :slight_smile:

And what’s more - it opens the door not only for sharing the same code across multiple places in your process but also for sharing your useful code snippets right here, on our Forum, for everyone to learn from them and to reuse.

Please share your thoughts below and let us know how we can further improve your experience!


I got inspired to write this short tutorial because of this reply from my colleague.


This is great! You can set breakpoints and step into the code which we never could do with Invoke Code. Also when there’s an exception, it actually shows where in the code the exception happened (in contrary to Invoke Code that basically just said that something went wrong).

The fact that arguments are added directly to the activity itself makes so much sense.

The EASE of passing arguments between coded automation and other workflow types was the missing piece.

Good job guys.

1 Like

Can we invoke coded workflow in some other xaml instead of main.xaml?

Like in between the automation, I want to perform some activities using coded workflow so I wanted to invoke it in some nested xamls.

1 Like

Of course, it is in this way functionally the same as when you invoke a normal xaml file workflow.


when i tried to execute the code I got an error
The type or namespace name ‘Dictionary<,>’ could not be found (are you missing a using directive or an assembly reference?)

adding using System.Collections.Generic; to the cs file solved

1 Like

I love this new feature. :slight_smile:

The invoke workflow file makes it very intuitive to use.
Thanks for the example videos, very easy to digest.

1 Like

Hi @loginerror,

thanks for putting together this guide. I am currently testing the interoperability of coded workflows in library projects and I have noticed a couple of things:

  1. The coded workflow files do not have the option “Make Private” in the context menu. Thus, the end-user will see the *.cs file as an activity even if the file is meant to be private within the project. I’ve tried to declare the class as “internal” but didn’t help.


Is there a proper way to use *.cs files in library projects as private?

  1. I have the following scenario:

Main activity (what users get to see as activity card) → invokes based on the input arguments:
a. low-code workflow (private) → end;
b. coded workflow (supposed to be private) → invokes another low-code workflow (private) → end;

This works fine while testing. However, after publishing the library, when using the (b) branch the coded workflow is throwing an error saying that it cannot find the low-code workflow file to invoke.


Coded workflow:

Project structure:


Am I messing up something here or this isn’t supported? :thinking: Thank you!

1 Like

Hi @Jugger

Thank you for your feedback. I consulted it with the team working on the coded automation and the Make Private functionality is indeed not yet implemented.

The good news is that it is on the roadmap with the goal of having it match the existing capabilities of the original xaml file based automation.

Thus, as you discovered, for now, you can only Ignore from publish your .cs files, but this will make them uninvokable/inaccessible because they will not reach the final published package.

I think you could maybe work around this limitation (but by introducing some as well) by using the Code Source File .cs files. Those do not show up as a new activity either way and allow you to create a custom namespace for your project which you should be able to use with Invoke Code in the XAML files. So it could potentially fix your issue of having some custom code hidden from the library consumer, but it would mean that you cannot directly execute the activities as you can in a Coded Workflow; you would just have your own custom classes instead.

Hi, decided to give it a try today.
Downloaded the newest Enterprise studio version.

However in my projects when creating a coded automation workflow file.
Trying to use the Invoke Workflow File activity, it has the old version still ?


is it not supported in the enterprise version yet?

Hey @kali

All is good, and you are right. The new “look” of the Invoke workflow file activity is for now only available for cross platform projects.

In Windows projects you will still have to configure your inputs/outputs manually, but it will still work with a coded workflow file.

1 Like

Hi @Jugger, @loginerror !

Have you managed to solve the problem with the invocation when using branch (b)?

I have exactly the same problem. When I run the tests from the library, the entire process is correct, but when I run it from an external project I receive the same error.

In my case I am not ignoring any files in the publication.

Attached is a screenshot of the project in which the “Ebroker” library is installed. When “Click-Interactions” is executed, a ‘RunWorkflow(“Reusable\Click.cs”);’ is used inside

As I mentioned, if I run the test from the library, everything is correct. But from the external project I get the error.

Thank you!