Good coding practice


My xaml file code logic is too huge. Is it a good practice separate into multiple xaml files and use many invoke worklfows in a single xaml file. If yes, apart from readability does it improve performance as well?

Is it like separate xaml files are only created when that particular xaml has to be reused in code?


  • isolated subtasks helps the understanding process e.g. new members will join the team
  • isolated & direct testing option
  • replacement option
  • reducing code redundancies

just to mention a few points

No, not only when it will be reused, also when:
e.g. as mentioned above like, quick direct testing options, replacement …


It does not improve performance. It makes things more complicated, not less complicated. The proper use of a separate XAML and Invoke Workflow is only for code that is repeated.

Experience is my guide. Why complicate your code, making yourself have to deal with input and output arguments etc? This makes your code MORE complicated, not less complicated, and introduces a black box for future people who have to maintain or update your automation.

thats your opinion only, but not an official, reliable fact. However I will withdraw the question.

1 Like

If I am writing all my code in one xaml file, its very slow to open . Seeing buffer circle cursor for quite a long time. Does separating into multiple xamls help to solve this as well?
Thanks for your help

This cannot be a fact. Even if UiPath says it, it’s only their opinion.

I’m sharing my opinion from my decades of experience coding, including in UiPath.

Sorry you have a problem with others having a different opinion than you.

Are you opening them across a network?

I’m not sure if separating into separate XAMLs speeds up Studio load time. It seems logical that it would, though.

However, I have had very simple single XAML automations take a few moments to open in Studio, and I attribute this to opening it across a network I’m connected to via VPN.

No, we only prefer to collect official statements to turn it into Guide lines. Thats why we asked you. Do not over interpretate things.

Perfect can you share the link / ressource to this. Thanks for support :+1:

I didn’t say UiPath said it. I said even if they DID say it, it’s just an opinion. “Just an opinion” is not a valid reply, we are all just sharing opinions. Do you have something useful to add to this discussion?


Let’s go one by one

Yeah ofcourse it is a good practice and it depends on the process

Say for example if the process is within single window or application then it is good to have in one xaml

But if it involves multiple applications it is good to have separate xaml or group of separate xaml to handle the process in that application

So that if you face any changes in that application like if there is any upgrade in version of that application then it will require few changes to be done
By that time it will easy for you to manage them and you don’t need to search for long time on where to include the changes being a single xaml

And you can also share with your team member if they are also trying to use the same application but with different process

For example login part of sap or any application will be the same inspite of different process

So that login part can be kept in a separate xaml and it can be used by others as well

There are many advantages like such

Hope this clarifies your query

Cheers @garimavarshney9

The number of changes required to fix this is no different whether you use different XAMLs or not.

Simply organize your code into relevant Sequences (ie “Process Page 1” “Process Page 2” etc) and it’s less difficult to find than with separate XAMLs.

This should be a custom activity, not a separate XAML. If you and I both have “login.xaml” in our projects, when you change yours mine doesn’t change.

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