Feature or a Bug?

Hey all!

Came across something and I am not sure if it is a feature in .NET or just a UiPath bug. Say I create a data table or a dictionary in my main workflow and pass it to a sub workflow. If I pass either of those variable types in as an “in” argument, I can still write to them and the changes will be reflected in my main workflow.

Can someone help illuminate this for me?

Like always, thanks for any time you give this post!

-James Mills

This is a bug. Though some programming languages work this way, this is unintended behavior for UiPath Studio.


In RE Framework, transactionItem is passed to process as in_TransactionItem and not as io_TransactionItem. When working with DataTable/DataRow TransactionDate/TransactionItem it is convenient to update the transactionData by udpating in Process the in_TransactionItem. While the in/out/io argument passing direction might suggest some protection, I had to test if I needed to change again the framework to work with datatables: when updating in Process the in_TransactionItem, you change is reflected into the “global” TransactionData.

From that, I came to expect that arguments are passed by reference and that the reference might change into the invoked workflow’ scope for an immutable object type when changing the value but for a mutable object, the reference still persist while related objects are changed.

I’d like to have some insight from UiPath.

@msan That’s something about the REFramework I hadn’t noticed! I still think think if the object is mutable, Studio should automatically create a copy when using an In argument for mutable objects. Especially if the goal is to make creating automations in Studio more accessible to people without programming backgrounds.

1 Like


I’d like to see an Academy video about pointers :slight_smile: I agree with you that by reference vs value is difficult to grasp for beginners and that many UiPath users don’t even expect to dive in “coding considerations”.

At first glance, allowing to set Direction and Passing mechanism for arguments (with a default set to by value to keep it intuitive) might help to keep that notion quite explicit when looking for it and provide flexibility.


If you pass a copy of these instances as argument, you should be safe. Does instanciate a local variable from the argument do the trick?

True. The reference feature is fine as long as it’s clear for beginners how it works. Possibly by providing a warning in the project analyser if a mutable object is passed as an In argument.

1 Like

Is there something special about the data types of dictionaries and Data tables vs String/int/bool? Since the latter does not change when passed through as an in argument

As far as I know for VB, String, Int and Bool are immutable. It’s quite tricky to explain then I won’t risk to improvise an answser. Look at the wikipedia link below and feel free to ask about details.

EDIT: add a youtube link

It gets somewhat technical, but dictionaries in VB.Net are passed by reference, meaning that even if you pass the variable to a workflow, it will change if you change it. You have to explicitly make a copy if you don’t want to change the original. While I’m not sure what the original intention for separating the two was when immutable vs mutable objects were differentiated, I believe datatypes which can take a large amount of space were made mutable so a copy would not automatically be created when the object is passed, saving on memory.