Developer Opinion about UiPath Studio

Feedback Studio
, ,
1

I hope I am adding this post in the right place. I work somewhere where I keep hearing constant negative feedback about UiPath as a whole. I started off as a HelpDesk technician, but I am moving into becoming more and more of an RPA Developer. I am in love with automating everything that we possible can. But according to the company I am helping create RPA processes, I am not a “real” developer or I am just an “end user”.

So I have a question about UiPath Automation for developers out here using this. Do you believe this is an actual development product and if so, if used properly it could be used for proper automation?

I appreciate everyone who took the time to not only reply, if I get any, but also just the one’s who stopped by and read it. Just figured this would be a good place to vent I guess.

Thank you again.
Roy.

3

Hi @rsaquicela

There is always an alternative to any product we buy/use, be it a software or a consumer product. When it comes to software many parameters come into play to determine the feasibility to use that software like the purchaser’s infrastructure, knowledge etc

I started off my RPA journey with some other tool and switched to UiPath. Initially I was not at ease with UiPath but eventually I stated appreciating it for all the possibilities that I didn’t see in the other RPA tool I used. The point I’m trying to make is (from a Developer point of view) unless you learn and try out the different RPA tool by yourself you will not have facts to conclude which is better. But again priority is feasibility of the organization that is using the tool plays important role to determine which is better

4

Hi @rsaquicela,

Excellent to see that you being the end user have taken to love automation and are willing to upskill. If those developers who are negative towards UiPath have still managed to make you believe in RPA, imagine what you can develop when you do use UiPath the correct way :smiley: You know where this post is going!

The below is my opinion and stems from hands-on automating for close to 5 years in different tools / programming languages both as a professional and as a weekend automator! In short, it is subjective. I have used, Python, Javascript, PowerShell, Bash scripts, BAT scripts, Power query, Blue Prism, Robocorp, Power Automate and UiPath to automate mundane tasks.

Personally, I believe a good automation project needs to consider use of a multitude of tools as and when required. Each tool has its own strength and can help the other tool, but professionally in (2021-2023), I would choose UiPath even with the pain-points it has because of the time it saves my team and me. 95% of the time, I look forward to working in UiPath Studio in my workday. Let me elaborate.

Integrations in Studio

Be it API or custom code or script your team generates in C#, PowerShell, BAT or any other programing language are easy to integrate into UiPath projects.

Sheer performance and ease of Web-Automation

Native integrations in web-browser drivers such as chromium make web automations a cake walk in UiPath. It just works! From experience, a bot which took 11 minutes to scrape data in Blue Prism (which does not have good tools extractor scattered table data) vs. UiPath which took 33 seconds!

Dark mode

This to me is a must. We have to take care of our eyes, don’t want to be 55 and realize that a simple Dark Mode would have helped de-stress the eyes! As a full-time developer you will be actively looking at the studio for 4 to 6 hours a day. To me it is very difficult to look at a white studio / object studio (BluePrism, Power Automate!). It takes a toll on you quite soon. UiPath took this community feedback and took action.

Ui Explorer

Unlike most RPA tools, UiPath offers the best user experience when it comes to finding which selectors exists in an application. Each time you have to identify an element you get an option to open in in UiExplorer if you wish. There you can see the hierarchy of the whole application. Other tools also have this, but they are inferior to Ui Explorer.

Portability

No developer wants to develop the same thing twice. UiPath workflows can be packaged both as standalone .xaml or .nupkg files and consumed in any other project. This is not something unique to UiPath, but the implementation in other tools is time consuming.

Templates; once you like how your workflow or project looks and would like to convert it to a template, in a click of a button you can convert it to a template and store it such that other developers in your team also have access to it.

Version control

We all have crossed this path. Deleted something, which should not have. UiPath offers inbuilt version control integrations with local GIT / or remote TFS or Github or other providers. The ease of backing up in UiPath is great. You always know that your code is backed-up, which branch or repo you are in etc.

A lot more features to like

There are many more advantages with UiPath and Studio as a developer tool. The forum “tutorials” is a good place to gauge the capabilities of Studio. ( Latest News/Tutorials topics - UiPath Community Forum)

It is not all sunshine

Feature rush
UiPath is great in pushing out new features, but the speed at which they are growing makes it difficult for enterprises to port solutions. For example, say a new feature was released in 20.04 in just 6 months came an enormous update 20.10. You can ask anyone who maintains the UiPath infrastructure while knowing that the LTS (long-term support) window is just 2 years. They don’t like it, they just do it because they have to!

Debugging

Clearly, other RPA tools have better implementation of Debugging, which allow for better failure reporting. Without explicitly throwing an exception with good message, UiPath does not return where in the whole process the robot failed. Very vague auto generated failure messages. Another feature, which is missing, is you cannot just jump over some activities and continue in debugging mode. Blue Prism trumps here, excellent for finding out where the failure occurred and easy to manually debug.

License nightmare

When you start buying licenses in many other RPA tools it is all-or-nothing and I some cases you pay as you use (Robocorp). And there is UiPath who want to be modular and has setup each of their product with its own license. Great for companies, which choose the cloud version, but companies who want UiPath on-premises are left with a nightmare of maintaining and identifying license schemes.

  • You want orchestrator? – Orchestrator License
  • You want studio? – Studio Pro License
  • You want studio for more than 5 developers? – You cannot use Orchestrator basic license, upgrade required.
  • You want production robot? – Production License
  • You want nonproduction robot? – NonProduction License
  • You want attended robot? – Attended License
  • You want test robot? – Test License
  • You want a process surveillance? – You want Insights license
  • You want Document understanding? – Needs license

Other N number of licenses to follow. You get the point.

What started as a simple investment and profit can soon diminish if the scale of your RPA is small. For larger enterprises, the amount of cases robot handles makes it worthwhile. Nonetheless, communicating and following up these licenses is a repetitive job in itself!

This affects us at developers because we are responsible for license management and have to inform changes to the yearly budgets.

Summary

All in all, I would still recommend UiPath until a better tool comes over, which it will. It may be Power Automate or Robocorp for all we known. When you do start with UiPath also try to skill yourself in Power Automate. Microsoft is much better at license management and as RPA-technology moves towards API-based automation, a tool such as Power Automate is well suited and will have longer product lifecycle than UiPath, unless UiPath does something unexpectedly to its licensing structure and makes it easier for many companies to choose them.

Also, invest your time in PowerShell, BAT scripts, Python and C# if possible. These skills can be ported to any role in IT, so when RPA loses its hype and shine, you are ready to take on new challenges.

Last but not the least, since you are starting out in a new field, I would like to suggest a book: Deep Work: Rules for Focused Success in a Distracted World: Newport, Cal: 9781455586691: Amazon.com: Books

We wish you success in your RPA journey!

3 Likes
5

Thank you so much Aditya for your opinion on this. I think you stated it perfectly and enjoy to see someone who was not a fan but still decided to learn it enough to appreciate it.

6

I don’t work with UiPath for to long, but i can agree with the pros and cons @jeevith did list. The license situation is a mess and im glad i dont have to manage it, but rather my team leader does. Also highly agree on the dark mode. I would prefer dark mode over a slightly better software with no dark mode any time! :crescent_moon:

I have to admit i do get the “not a real dev” part as well. I used to programm with python, which feels WAY more like “real” programming than UiPath does.
Mostly because you often just drag & drop code in the dress of a UI element. Instead of going with:
if x == 10 or x == 100:
print(“x is 10(0)”)

you just take an element that says “if” and basiclly assamble the code by clicking on an UI. :sweat_smile:

So i do get that some devs would see UiPath as not real programming. But what they forget is, that you have to think like a programmer in order to assamble your code the propper way.

I think after not even 6 months of RPA Development, this is my point of view. I hope you enjoyed reading it!

greetings
Mahrie :bear:

7

Interesting topic, but not a good question, because UiPath is factually a development product and is factually used for proper automation (what is improper automation?). So yes and yes!

I’ve had some experience with different programming languages, but I have never actually worked as a conventional developer. However I have three years of experience working with UiPath products.

I think the reason why conventional developers tend to be negative about RPA is because of a stigmatization of low-code development. There is an assumption that low-code development translates to low-skill development.

Conventional developers had to learn and practice programming language syntax and complicated expressions. Now basically anybody with some affinity for technology and basic problem solving skills can come along, be a citizen developer and deploy a working software solution within a day!

Some developers might even feel threatened by this fact the same way some workers are scared of robots taking over their jobs.

Think about it: essentially low-code development such as UiPath automates the repetitive tasks of conventional developers by substituting code blocks with these user friendly activities in a graphical interface.

I think knowing some complicated coding syntax doesn’t make you high-skilled and I prefer having UiPath do most of the code syntax for me, so I can use my mental resources on more important things like solution architecture or problem solving. These are the more skillful areas of RPA in my opinion and they bridge the gap between development and operations:

It is easy to build an RPA-workflow. It is much harder to build a stable, resilient, scalable, flexible automation solution which keeps operating and operating! So I guess to me the difference between an “end user” and a “real” developer in RPA is not the coding skills itself, but the ability to develop, test and deploy a well rounded solution.

2 Likes
8

Hi Jeevith,

Extremely appreciate your well thought out point of view. I love you broke down each good and bad part of this. Thank you so much for taking the time to write this up and definitely motivates me to keep learning this amazing product.

9

I like your take on this topic and think you hit the nail on the head with it. Thank you so much for your point of view of this, I believe you are completely correct here.

1 Like
10

@jeevith I would like to thank you for the honest feedback and ensure you we are working on the pain points you listed.

  • Our LTS versions have 3 years of support so you are not obliged to upgrade unless you want to benefit from the latest features;
  • What are you missing in terms of debugging? This is an important area and we are continuously bringing improvements. In 21.10 we brought remote debugging and the ability to change properties of activities during debugging.;
  • We retired StudioPro license as a start to simplify developer access to advanced features.