UiPath Reviews

We are using the on-premises UiPath solution for both attended and unattended bots. At this time, we use unattended bots primarily to facilitate integration between applications, and we are not using the attended bot capabilities.

Generally speaking, we develop integrations for our core banking system, which was written in-house and running on a mainframe. It is a highly-developed system that we started using more than 30 years ago. When it was created, we didn't have the integration capabilities that exist in other applications or core systems, today. This means that in order to have external applications communicate with the core system, we need to develop integrations. Examples of this might be web services or other APIs, and that's why it takes time to do.

We have teams to do the integration, but considering that the core banking system is in Turkey and all of our teams are busy, we don't have enough resources to implement all of our integration projects. Now, for the past three years, we have been implementing bots to handle integration by moving data from the applications to the core system, and from the core system to the applications.

The biggest benefit for us is time savings in terms of developing satellite applications for the core banking system. We are developing the robotic API, and we are integrating our internal front-end applications with the core system.

Using this approach, we can easily get and set data from the core system, and we can see the results for each transition. We can learn about what happens in the core system with the help of the bots.

The amount of time that we save depends on the use case. For example, if we implement integration between core banking and the applications instead of native integration through development, it saves a lot of time. I prefer native integration versus using the bots but sometimes, you don't have this opportunity because it will take too long to put into production. Other times, you can't justify undergoing a large development process for just a small integration, so it's enough to solve the problem using the bots.

There is another use case where our operations teams perform repetitive tasks using the bots. For example, when performing the task manually, users have to take the data from one screen and enter it on another screen. We have never tried to calculate how much time we are saving in cases like this, although I'm sure that we are saving a lot of time.

People in the organization have been asking for more projects to be automated because it is easier for them. When their tasks are automated, they are more relaxed and can focus on other more important tasks, as opposed to the repetitive ones. Getting away from repetitive tasks puts you in a position where you can make more decisions and be part of the smart part of the business. This leaves the easier, repetitive tasks for the robots.

There are a lot of really useful features in UiPath including the Orchestrator and the Studio.

The Orchestrator is one of the main tools that I use because I like to help orchestrate the bots. It is the heart of the tool and it gives me a lot of flexibility to automate or manage bots that are in the field. The Orchestration Server is one of the most important features and when you perform a deep dive, you see that it has a lot of functionality. It's great.

The Orchestrator has other features such as computer vision, AI, and machine learning, and it complements the bots and the Studio.

UiPath integrates well with Elasticsearch, which is a great search engine. ElasticSearch is more capable than UiPath for searching logs. I'm filling the gap in log reporting using ElasticSearch, where I'm feeding the logs into it and then creating dashboards, or using the analytics parts of ElasticSearch and Kibana.

The UiPath Academy is a very valuable component of this solution. Many of our employees have used the courses. With it, a person who has a little bit of an analytical mindset can easily learn to do many things. If somebody is willing to develop themselves in RPA, the UiPath academy is more than enough to do so. They will understand the components that make up the ecosystem. The academy is very good, well constructed, and has a lot of labs and exercises to help one learn the system by themself without any help, and very easily.

The logging capability that comes with Orchestrator does not allow you to create smart reports. You have the logs from the bots and what's happening on the machines because you get all of this information from the logs. However, UiPath is more capable when it comes to collecting information about your processes, time saved, or process execution. They have some smart report dashboards.

The installation and initial setup is difficult for non-technical organizations.

We have been using UiPath for more than three years.

Stability is something that we should consider in two parts. The first concerns the bots and how they are running the tasks on the machines. This comes down to what kind of developers we have because if you are developing properly, and implementing all of the exceptional cases that may occur during the execution of the process, it's very good. I haven't had any issues in cases like this.

The second part is the Orchestrator, and I haven't had issues with this either. In the more than three years that we have been using this environment, including the time in production and our test environments, we have never had an issue.

We have had two or three incidents because we didn't have enough space left on the database storage, but that was not related to UiPath. Rather, it is related to the infrastructure. Another time, the SSL certification expired so we had to renew it. Otherwise, stability-wise, we haven't had any problems.

Scalability is very good, although we have not reached a point where we needed to scale the infrastructure. The high availability and scalability are two of the main features in the UiPath environment but we have not needed to go in that direction yet. At this time, we only have five bots in the organization and that is enough.

We are not planning to increase the numbers at this point because the number of bots that we have can be managed on a single node. We don't have clusters or multiple bots because of the criticality of our processes, but these are things that you can add and set up to share the workloads. Although we don't use it, I think that it looks really promising.

In our team, we have a business analyst and developers. Some of the roles for the developers are varied. At most, we have three people on a project who are working with UiPath.

The technical support for UiPath is good. When we first started contacting them between two and three years ago, the support for everybody was the same. However, they're now offering different tiers of support that require a different license and cost. There is one basic technical support, where all customers have the right to open tickets and try to solve the problems. Then, there are different support levels where you can pay extra and you can get more assistance for solving your problems.

Up to this point, all of the problems that I have had are mostly related to upgrades and installations, and they have only been from time to time. So far, I have been able to solve problems with basic technical support. Some of the problems I have solved on my own, whereas with others, I have needed a small bit of help from technical support.

I can say at this point that the support is good, although really, I haven't had any major problems that necessitated a lot of support.

We have used other RPA solutions in the past, but not to the same scale as UiPath.

The initial setup is not very complex, but it depends on the profile and experience of the person who is using it. Considering we had a great deal of deep experience in the project implementation and also the technologies, we are familiar with everything. This includes tasks like installation of the infrastructure, configuring the databases, configuring the virtual machines, and installing the robots' features.

For less technical organizations or people, it will be difficult to implement the UiPath infrastructure. In that case, they will need the help of partners.

It's not so easy, but it's well documented. In fact, one of the good things about UiPath is that everything is very well documented. The deployment takes no more than two or three weeks.

Our implementation strategy started with developing bots using the trial license. We found the bot implementation was very easy. The trial includes everything that you need to develop workflows and the bots that run on the machines. When you get to the point where you need to run multiple bots in production, you need the Orchestration server.

We did not install Orchestrator until between four and six months after we started with the trial. In the beginning, we were testing UiPath and creating some small projects. These were very easy to implement. After that is when we decided to buy the license and move the bots to production.

In terms of maintenance, it is not critical for the bots. It's the Orchestrator that has to be maintained and kept up to date. Every year, you need to upgrade your infrastructure with the latest release, so there is some annual maintenance. If it is on-premises then you also have to maintain the hardware that everything is running on.

Of course, there should be somebody responsible for taking care of the databases and general system maintenance. The operating system, for example, should be maintained by someone. All of these things are layers and sublayers on top of the solution.

If instead, you implement the cloud version of UiPath, then you can get rid of all of the maintenance. In that case, you have only the bots and the Orchestrator, which are hosted on the UiPath cloud, and you don't have to worry about anything. UiPath does the upgrades and performs all of the maintenance, which is nice. In the future, we may go in this direction. However, at this time, maintaining the infrastructure in our organization is easy and not a burden for us.

I can't say that UiPath is expensive but I can't say that it's cheap. The cost that we are allocating for RPA doesn't burden us too heavily, so what we are paying is acceptable compared to the gains that we have in the organization. That said, it is relative because it depends on the size of the organization, the budget, and other factors. From our point of view, considering our budget, it is okay but for another organization, it might be expensive.

There are some features, such as UiPath Insights, that require you to purchase an additional license. The logging capabilities are also a feature that you need to pay extra for.

While we were searching for solutions, we read the documentation for UiPath. We found out that UiPath was originally started as a Romanian company, where we are, so we figured that we would try it since this is where it was first implemented. Our tests showed that UiPath was very promising but we kept investigating other solutions.

We tried Blue Prism and we tried Automation Anywhere, which are both RPA tools. We also did some studying, looked at the Gartner report, and did some further analysis. Ultimately, we decided to buy the licenses from UiPath because it was solving all of our problems.

When you use this system, you are using features from several different modules. It's something like an ecosystem where you have the bots, Studio, and the Orchestrator. If you are not using all of them at the same time then something is missing. They complete each other. If, for example, you don't have the Orchestrator and are only running the bots then it is a different kind of automation.

In the past, as I was using UiPath, I found that there were additional features that I wanted, but regularly and with each product update, they were bringing in new functionalities. At this time, I don't have a project that is waiting and cannot be implemented due to missing features. All of the tools that they deliver, for the time being, together are enough to implement any type of project.

We are not yet using the AI functionality because to this point, although that is because we don't yet have a proper project for it. At the same time, the AI and machine learning functionality are very important to us because we are planning to use them.

We have not used the UiPath Apps feature because it is one of the new features that has come out lately, and we haven't had the time to gain a deep understanding of these technologies. We have some rough ideas about how we can use this feature, but for the time being, we do not have a project that needs to be solved with UiPath Apps.

My advice for anybody who is implementing UiPath is to start with studying the processes and trying to determine whether they are good candidates for RPA. In order to automate a process, you need structured data such that the inputs and outputs are somewhat predictable. Once you know what it is that you want to automate, you have to understand the capacity, and then if you have any candidate processes, you can begin developing.

UiPath is the RPA solution that I recommend. However, it is important to know, before purchasing a solution, which of the processes are good candidates for automation.

I would rate this solution a nine out of ten.

Most of our use cases are related to business, like reconciliation and reporting. Therein, they have some internal applications to automate SAP automation and Salesforce Automation. Our most recent use case is related to documents, like the invoices coming from customers. We have to extract that data from invoices via different formats, e.g., some are digital formats and some are scanned formats. So, we have to extract the data, which we are doing with the help of UiPath.

We are using both attended and unattended automation. For 90 percent of our use cases, we are using UiPath for unattended automation.

I use UiPath almost every day. When I finish developing one process, there is a new process to develop. If a process is complex, it almost takes six to eight weeks to develop it, then you have to deploy it for monitoring. After that, the next process comes up.

UiPath helps based on how it is configured. In our case, there are so many transactions coming in, it is not possible for a human to complete them in nine hours (working hours). So, we went with unattended bots, which we mostly run at night. We start the bots after the working hours of humans, so when the operations team returns in the morning, their work is complete.

From a developer perspective, the process is smooth and easy. You can find a solution on Google easily. You can develop your own code. From a technical perspective, it is 100 percent.

UiPath Studio is great. It has all the activities. You don't have to write anything. Even after that, if you feel that you have to do something for yourself, then you can write your on-premises code in it and develop your own framework. Everything is there. You just have to use UiPath Studio.

if you are a business user, even if you don't have a technical team, you can install the second version of the Community edition, which is StudioX. This is specifically made for business people who don't have a lot of ideas about technicalities. This is a great feature.

If websites are made in a recent programming format, it is very easy to automate them with the help of UiPath. However, if that technology is based on legacy applications, then it is very fragile and hard to do that. So, we have to choose the technology first, and if the technology is new, then you can easily automate it with other applications or the help of an RPA tool.

The process can be complex if an application is a legacy application or the data is unstructured. The analysis of some bots is lacking. If a customer asks for analysis of a particular bot, you cannot just get the data from the UiPath and give it to the customer. It is not that easy. I would rate this process as a seven or eight (out of 10).

The Document Understanding feature should be more developed and advanced. For example, you have to make a template with their ML model. Currently, we can't use our own ML model, and we have to use the UiPath ML model. UiPath has only a few ML models right now. They should come up with more ML models or make it easier for us to use our own ML model. While they are working on this, I have felt much difficulty in extracting data during our last process for Document Understanding. We had to go with the Python language. So, I think they are lacking in this feature.

After deploying the bots in production, processes are very stable, unless something happens with the machine. You don't have to monitor a process every time. So, I am very impressed and satisfied with things.

We are looking to update to version 20.

This solution is very much scalable. If you are working in a small or large organization, it doesn't matter. It is very much scalable, up to anything.

We have a team of around 100 to 120 people in RPA automation, in which 60 or 70 users have the developer license. 

I am very much impressed and satisfied with the UiPath solution. Earlier, I used the Automation Anywhere solution, and it is sort of messy and complex. You have to pull everything from a single workflow. Then, I moved to UiPath, and everything was very sorted. If you really like coding, you can do that. It gives you a real developer type feel.

Developing and deploying robots with UiPath is very straightforward. It hardly takes five minutes to deploy a process on Orchestrator.

The last process that UiPath covered saved the work of two people.

If you have repetitive tasks, you can apply UiPath and have your people trained to do other work.

If you want to start doing RPA, I think you should definitely go with UiPath because it has the Community edition. You can just install it and check whether or not your process works fine with UiPath. It will be an attended bot, but you can form an idea whether your bot can easily be automated.

We have one use case related to Microsoft Word Automation. Word Automation is not compatible with other tools. However, in UiPath, we were able to write our own code to automate and format the Word document, which is why UiPath Studio is the most valuable feature. We are also using the Automation Anywhere. But, in Automation Anywhere, we cannot write our own code. So, we can't automate Word Automation from Automation Anywhere as well.

Automation Anywhere has come out with its own new version of 2019, which is as effective as UiPath. However, when I have tried to run or deploy the bots, it still lacks in features. For example, in UiPath, AML activities are coming up very frequently. Whereas, in Automation Anywhere, these features are lacking, which is why I go with UiPath. Also, Citrix automation is very good with UiPath. You feel like you are able to detect the elements and images.

UiPath gives you REFramework, which is absolutely amazing for business use cases. Automation Anywhere also lacks this feature. With Automation Anywhere, you need to make your own framework, and if you are making your own framework, then the look becomes messy. If someone is trying to understand it, then they have to spend more time on the framework to understand it.

I use the IQ Bot of Automation Anywhere, and even after training a hundred documents, it's not picking up or extracting the data from documents. I feel like I have to train the model again, which is not the case with Document Understanding. If you properly make the templates in Document Understanding of UiPath, it gives you full text values. So, it is more advanced and suitable for me.

We use UiPath Assistant to run processes about 10 percent of the time. Most of the time, we are using Orchestrator. 

UiPath releases new features every 15 days to a month. They have already come up with AI and machine learning.

If scanned documents are coming in for some of the work, we are also using Python language for this.

If you already have a technical team, then you can ask them to look into UiPath Academy. If they have basic knowledge of programming or coding, then even in seven days, they can easily learn UiPath and start applying it in their organization. You don't need to hire outside developers.

Overall, the solution is a nine (out of 10).

We are in the finance industry, so we use Studio and Orchestrator to automate a lot of Excels and making reports.

The product has given us the opportunity to automate processes for our industry and specifically for our business. We have set up best practices. So we know what description needs to be at the top in the code. We just start there, read what's going on. Automation just makes everything simple and standardized while reducing human error.

I don't know all of the features so the scope of my view is a little limited as to what may be best or most valuable overall. For me, the ease of use is definitely valuable. Assembly of processes is just drag-and-drop and that simplifies a lot of things. Annotation is also very easy to do and it helps to make things clear to understand during development. I can go look at someone else's code and within an hour understand what it's doing without having to consult the other developer. On a scale from one to five where one is very difficult and five is great, I would rate the ease of use of the platform a four. 

Even though there are things I'd like to see, I also know that most or all of them are already being announced for new releases. As a developer, I would probably say the most important thing I would like to see is that the IDE (Integrated Development Environment) a little bit more fleshed out. It could use more debugging capabilities, for example. But again, we've been seeing that they're adding stuff like that. It will be getting in there and playing with it when it is released to make sure that it has got all the stuff I want and I might be able to be more specific after that as to what still needs to be added.

On a scale from one to five where five means the product is very stable, I would rate the stability of the UiPath platform a five. It works and nothing breaks that is directly related to the product itself.

The technical support, communities, and resources are all pretty good. We use the forums and I like the forums a lot. It's crazy how many people actually spend time on it and reply. You get your answer pretty quickly. The guys are really open to work with, so if we need help we just reach out and we get all the help we need.

We also use the UiPath Academy. On a scale from one to five where one is the least beneficial, I would rate the Academy as probably four out of five. It is easy to use. You go in there and you know what training you are looking for and what you need to take. Most of the training is in-depth enough so that when you complete it, you really have a good grip on what's going on. It eliminates barriers to getting the information you need when you need it.

The initial setup and implementation happened before my time at the company.

A lot of our return on investment has to do with time savings. It is definitely amazing to see processes that could take eight days before actually run in ten minutes. Just because of automation. It eliminates Hangouts and just makes the whole process and the people involved in the processes more efficient. As far as how much gets saved exactly, it depends on the complexity of the project and what it resolves. We have to invest in our BA (Business Analyst) work so all together it may take a couple of months for anyone project to pay off.

We use the solution on-premises right now, but I think we are going to move to the cloud because of the advantages. We also do not run our automation in a virtual environment, such as Citrix either. Our bots run on a physical server, but there may be reasons in the future to explore virtual environments for that purpose. 

The approximate number of people in our organization involved in the automation initiative, strictly considering developers would be my team of six. It is harder to say how many are using the bot solutions who are not directly involved in the development.

We currently tend to stick more with attended bots which just helps take a measure of human error out of the way. A lot of problems that we had in the past have come from users not updating their personal machines. That can obviously cause things to break. We try to make bots unattended if we can, but it isn't always practical to deploy in that model.

In any case, the solution has definitely saved our organization time and reduces human error either way.

On a scale from one to ten where one is the worst and ten is the best, I would rate the product as a nine or ten. Beyond just the product, there are tons of resources that we have available. Finding things other people have already made is an additional benefit. There's no point in reinventing the wheel if something's already been built.

My advice to people considering the solution is pretty simple. Buy it.

We play significantly in the BFSI and healthcare space. A lot of use cases have been related to BFSI. Insurance is much bigger, with claims and underwriting, policy admin, health benefits, and so on so forth. There are also good use cases on the functional level, HR and finance, and that cuts across industries. 

As an example, looking at fatality insurance for pets, clients had a high volume of documents come in, claims in all different forms, and they had to apply logic eligibility. There's a simple rule of whether you allow or disallow. If they don't allow the claim, then there's a comp process. By a sheer ability to read whichever way the document comes in, clients are able to load the system and quickly get the eligibility. 

This dramatically improves their claims operation by a big margin. Whenever there is some complexity in one, then we do an exception. We crunched the time so well and made the process so cost-effective it has given the client a huge benefit.

The democratization, automation, and attended automation, all of these are pretty good features. Those are all good value add to what it was there previously. 

The moment a machine takes over, there are fewer errors. That is inherent. When you say value, that is the cost-benefit. 

We have seen a lot of benefits on the backend, but then the algorithm is constrained, which can't transform because of the older technology. 

Sometimes in their partner communication, they aren't consistent. This maybe is related to the fact they are growing as a company.

The solution is fairly stable. 

The initial setup is always complex. Clients don't know the hardware, the licensing, or how it works. Any large organization will always have an initial hurdle. 

We have roughly around 164-165 trained RPA credentials on the engineering side, all on UiPath.

You do have complexity when it comes to maintenance, as you get to 50, 100 bots. 

As an example, one of the customers for whom we did an early bird, we estimated we could save this one division of their company $44 million. They only may have to invest about $4 million. There's $44.5 million for about 12 months. That's what we think we could save. 

The adoption of RPA has definitely been increasing and we know that all of that has been largely in the back office. In the back office, it's easier to check ROI. We've actually gone beyond ROI because ROI is a very simple statement, so we start showing clients value.

How long it takes to achieve ROI actually depends upon the client's way of implementing it. For example, some people will wait to take away the manual effort while they will stand by. Because what if it doesn't work? What if it fails? What if then my backlog increases dramatically? So, it is really up to them. If it is simple task automation, we can do it in about four or six weeks. In eight to 10 weeks they'll see the benefit. 

We're using all components of UiPath: attended, unattended robotics, and Orchestrator Studio. We have a very wide customer base and our clients use all of them.

Cloud adoption is increasing. Deployment models are a little bit more a logistic question than anything else because companies who want on-site are a little bit more conscious of security, but they take a normal amount of time, just to figure out the infrastructure. If we moved clients to the cloud, we can make it easier to implement. With email on the cloud, they have a huge set of processes. The larger the company, the larger the processing. With the cloud, it becomes faster. 

I've got a deep partnership with UiPath. I would absolutely rate them high. I'd give them a ten out of ten.

I piloted the introduction of UiPath to my team with two projects. The first, domain monitoring, automated our ten-plus Pega applications' quarterly security and health checks. We designed an architecture that could be mapped across all domains, streamlining the process to run weekly instead of quarterly. This provided timely reports on application health via Webex. The second project was a more straightforward test suite automation for another UI-based application. These two successful pilot projects showcased the capabilities of UiPath, with the domain monitoring still in use today.

Building automation with UiPath is straightforward, but it's essential to be familiar with the target application and have a basic understanding of coding and if-else statements. This knowledge will help troubleshoot any unexpected errors. Overall, I'd rate the ease of building automation with UiPath an eight out of ten.

While working on the projects, we used two versions of UiPath: the enterprise and cloud versions. The orchestrator that comes with the enterprise version is different from the cloud version. The cloud version had better end-to-end automation, and the ease of use and accessibility were superior to those of the enterprise orchestrator, which is the on-premise version of UiPath. Although the enterprise version lacks a few features, the cloud version provides a complete solution.

I was impressed by UiPath's user community. We used an open-source library that someone else had built and generously shared with the UiPath community. It ideally suited our needs. The user community is also very responsive, and we readily receive answers to our questions.

We didn't see immediate benefits from UiPath because it was a new tool I was piloting. We had to prove to upper management that it saved significant time, and we eventually eliminated manual testing. It took until the project's end to demonstrate this, as management focuses on results, not processes. However, other teams adopted UiPath after completion, so benefits appeared after two or three months. It took time to get people on board, but they eventually embraced the idea.

UiPath has significantly improved our efficiency by automating domain and application monitoring, saving valuable time and working hours. These tasks were previously quite intensive and repetitive, demanding considerable focus and effort from our employees. With UiPath handling these processes, we've freed up our workforce to take on more engaging and strategic responsibilities.

My favorite aspect of UiPath is its user-friendly interface, as it's a no-code, low-code platform that eliminates the need for extensive coding. Its drag-and-drop functionality, coupled with UiPath's comprehensive library suite, simplifies automation tasks. For instance, the Microsoft Outlook and SharePoint libraries allow seamless integration with those platforms, streamlining processes like connecting to SharePoint in Microsoft 365. In essence, the combination of UiPath's robust infrastructure and versatile tools significantly enhances its usability and effectiveness.

I found the UiPath Academy courses to be a bit rigid in their curriculum. It was more beneficial for me to learn from the forums and YouTube videos. Their courses were tailored to particular roles, with a course on UiPath in data science being heavily focused on Excel. While it was a well-structured course, it didn't align with my job's limited use of Excel. Overall, their courses are well-built, but I found YouTube a more suitable learning platform for my needs.

UiPath Studio provides comprehensive tools and libraries for building automation, but it lacks a built-in feature to generate consolidated reports after automation runs, detailing successes, failures, and operational features. This absence of detailed logging information makes it difficult to troubleshoot issues and identify whether the problem lies within the application or the automation itself. While UiPath's orchestrator website provides some information, it's insufficient for demonstrating automation runs and accomplished features to stakeholders. Although a future release may address this, the lack of robust reporting capabilities remains a significant area for improvement. Additionally, UiPath's diverse suite of licenses can confuse end-users, making it challenging to determine the most suitable option. While the company has improved features, the increased number of licenses creates a knowledge gap between what's available and user understanding. Clearer explanations of each license would simplify decision-making for potential users and streamline adoption.

I have been using UiPath for one year.

Once we have the licensed version of UiPath, we don't anticipate issues with caching. We were using the 2021 Studio version because it was stable. Although the UiPath team suggested upgrading, I'm not certain about the reasons. I can't comment on the latest models, but the 2021 version was reliable.

The scalability of UiPath depends on the number of licenses. To deploy our automation, we need to utilize robots responsible for executing the automation we've built in a user-less environment. Scalability is directly proportional to the number of robots we have, which is, in turn, determined by the number of licenses. Therefore, more licenses translate to greater scalability.

The initial onboarding of UiPath was straightforward, but the only challenge we encountered was connecting UiPath Studio to the Orchestrator. UiPath Studio is where automations are built, while the Orchestrator is where they are deployed and run. This required some back-and-forth with the product team and my technical lead. However, this issue only arises during the initial setup. Once someone familiar with the process sets it up, it becomes easier. There were some challenges connecting and deploying the first automation, specifically between the Orchestrator and Studio.

Three people were involved in the deployment: my technical lead, who liaised with the product team to discuss progress and challenges; myself, responsible for building and deploying the automation; and one of my junior colleagues, who assisted me. In short, we had a three-person team.

We used UiPath and built and deployed that project, which ran successfully for approximately two quarters while I was away. However, the cost and licensing associated with UiPath became an issue. The license we were using offered excellent features specific to our needs, but it didn't provide much beyond that. It didn't make sense to continue spending much money on UiPath, even though it saved us time and money. The savings were essentially being reinvested back into purchasing the UiPath license. While UiPath licenses offer valuable features, they are expensive. For our single-use case, investing that much wasn't justifiable. We switched to Selenium, an open-source automation tool. Although it took additional time to deploy the same solution with Selenium, and it might not be a 100 percent match in functionality, it allowed us to save on costs.

The cost of UiPath is justified for organizations with many use cases but not for one or two use cases.

I give UiPath a seven out of ten.

The advice I'd like to give new UiPath users is to first understand their specific use case for UiPath. I've noticed some teams try to adopt UiPath by first figuring out a solution and then trying to retrofit it to their existing problems. Instead, I suggest thoroughly understanding the problem before creating a solution. Many teams see others using UiPath and assume it's a cool new tool they can simply apply to their existing issues. This approach rarely leads to optimal results. You might be able to build a solution, but it won't be the most efficient. For first-time users, I recommend understanding your problem, then exploring UiPath's capabilities to determine the best solution. There are plenty of resources available, like forums and YouTube, to help with the building process. Remember, understand the problem first, then build the solution.

I am a consultant working on RPA solutions in general. UiPath is one of the solutions that I am using.

The use cases depend on the clients. I have done automation of sending mail with invoices in it. We have used it for analyzing PDF documents, getting information out of these documents, preparing in three different languages depending on the client, and sending invoices by email.

We are also checking VAT numbers on the EU side to validate the client's VAT numbers and related data. We have automated the generation of reports out of SAP for two different managers and teams. We have also automated including specific signature images within PDF documents and sending them to the related service or email address.

We have mainly used UiPath to focus on processes related to the finance department. The targeted processes are the ones that are the most repeatable and require a lot of effort but there is no real focus and attention from the user. Because of its repeatable nature, the risk is that users do not pay attention to the process itself and make mistakes.

Generally, we do not implement end-to-end automation. The idea is not to automate an end-to-end process but to automate a part of the process that takes a lot of time and resources. That is the focus point, so it is not a matter of having an end-to-end process implemented. It may occur, but often, it is a part of the process where the focus needs to be reliability or time and resource consumption.

The benefit for our clients is time and reliability. They quite often see the benefits in terms of the reliability of executing the process, even reporting mistakes or errors that happen during the execution of the process. That is something quite valuable for them.

Usually, it takes our clients at least one month to realize the benefits. If the processes are executed on a daily basis, then it is quite fast, but there are processes that are triggered every month or every quarter. In that case, it will take at least a month or a quarter to see the benefits. Once it is executed, there is quite an immediate benefit. On the other hand, it takes time to analyze the process because often processes or procedures that are written are not in sync with what is executed by the user. We have to modify them. Often, by questioning the end user, you end up finding the shortcuts and implementing them, so the analysis takes more time, and the implementation takes less time.

UiPath reduces human error. That is one of the main reasons why automation is done for customers. Two main reasons for automation are reliability and resource availability. 

UiPath saves time for our customers, but it is hard to know how much time it has saved because it varies from process to process. For example, the process of validating the VAT numbers on the EU website used to take two or three resources every quarter, whereas now, it is reduced to less than half an hour. These time savings are valuable, but the added value is reliability.

UiPath has not had a lot of impact on the digital transformation because the processes that are requested to be automated are already digital. The reason for automation is to speed up the process or make it more reliable. There is no real impact on the digitization of processes.

In terms of the reduction in the on-premises footprint, I am not always aware of the eventual use of the processes that I am implementing for the clients with the bots. I see that some of the bots are not used anymore because they have their own application that includes a big part of what has been automated on their side. It depends on the way they use it and how often they use it because I have bots that are running every day, and I also have bots that are running once a quarter. The ones that are running every quarter are harder to evaluate because people are not always able to see the resources released from executing those processes. Because they are executed every quarter, they are usually not measured. Our clients generally go for automation for reliability.

Specifically in the recent versions, the ability to change the interface is valuable. One of my clients had to upgrade the SAP version and move to a web-based UI. This was handled by isolating the UI interaction within the library for the targeted SAP on the client side. I upgraded that library to handle the web-based, and the bots worked fine after that without modifying anything in them. The usage of libraries is very important for me because it helps a lot in this kind of upgrade, specifically because SAP is used across the company. It is impacting a lot of different businesses within the company.

It is quite intuitive and fully handled by a visual interface. It is no big deal for me. I have been a developer in the past, and I have used Visual Basic and C#. If I need to specify something exceptional, it can be done. It is not a big deal. For me, it is very easy. There is a competitor with an open-source solution called OpenRPA, but for me, UiPath is far better and more intuitive.

There should be the ability to customize the building blocks instead of having to specify everything in every step. We should be able to combine these building blocks to make specific processes faster.

There should also be some kind of templates, similar to Power Automate. Power Automate provides templates for a specific context.

I have been using UiPath for two and a half years.

I am absolutely satisfied with its stability.

I did not have to worry about it so much because usually, my clients want to take control of their bots. They want to execute it when they want, so I have had no experience with the scalability of UiPath. 

I have not contacted their support. When I am developing, I try to make a bot quite stable. I am aware of what is happening and what it is doing, and I can notify people with logs or names of different events that are occurring during the process execution. I know exactly what is happening and where. It is quite easy and fast to diagnose and fix if there is an issue, but it is not often that I have to intervene in production. If a process is designed correctly and safely, not much intervention is required. Clients look for this kind of stability because that will save the time that they will have to spend fixing things in the production environment.

They have a UiPath Community, but I have not used it often. If there is something blocking, I go over there, but generally, I find the solution to the issues through my colleagues.

It has always been on-premises. The setup is quite straightforward. If there is some kind of Orchestrator to be installed, it is more difficult, and it takes more time. Usually, they want to have someone internally to handle the Orchestrator. I am more focused on the bots and the triggers for these bots to be executed. I am not that often involved in the implementation of the infrastructure of UiPath for the operational side.

Bot development duration varies. It depends on the process, but it can take a few weeks to several months. I have bots that were developed in two or three weeks, and I also have bots that took at least six months because they were quite heavy and complex. Generally, it does not take longer than that because then it will not be as valuable to the clients. If it takes more than six months, it is better to have it developed in their own software.

Bot deployment is quite straightforward for most of my clients because, during development time, I take care of environment parameters. So, deployment is quite straightforward. It is a matter of deploying and pressing a button to have the package deployed. We then set parameters in config files, but it does not take a long time to have it deployed.

Bots usually do not require any maintenance, but if the source of data has been upgraded or modified or the UI has been modified, they might require some maintenance. Usually, once the process is running and every source is stable, there is no need for maintenance. When the data source changes or the infrastructure changes, such as the main server being moved or renamed, then there is a risk over there, but it is not a big deal to adapt.

Generally, two or three people might have to investigate the cause of the issue. If the issue is inside the bot, it is not a problem. One person is enough. If it is related to external data sources or infrastructure, it may take two or three people depending on the segmentation of the clients' people in their departments and services.

I do not know about the exact price because I am not selling anything. I propose several solutions to the clients, and the client does choose one of them. If UiPath is chosen, they contact the official reseller in the country. In one case, I had the prices in front of me, and it was not expensive for the service it was providing.

I would recommend it depending on the needs. UiPath can do a lot of things, and I have covered only 20% of UiPath functionality. Based on my experience and the needs that I had so far, UiPath has been quite valuable.

I would advise defining your use cases. That is the rule for everything. Once you have the use cases analyzed, you can specify what is needed, how you would do it, and what is the best solution to have it implemented. One thing that I am doing is that I am mixing solutions, where, for example, UiPath interacts with Python processes that I have developed. Python processes provide information in files. Web scraping is not difficult in UiPath, but it is quite heavy. In Python, it is faster to develop and use than with UiPath. It also depends on the number of iterations and resources available to execute it. It is a matter of the quality of a particular functionality in UiPath. UiPath relies on the .Net framework, and it has its own limitations. It has quite a heavy set of libraries and frameworks. It is a matter of balancing what you are expecting of it.

I would rate UiPath an eight out of ten. It is a good product. It is well-designed and well-executed.

The primary use case for document processing, automating data extraction from previously hard-to-access documents. This saves time, reduces manual work, and makes hidden data more accessible and usable.

It allows us to extract valuable information from various documents, categorize them based on their types, and make the data within these documents usable for our needs.

Assessing an AI center's role in orchestrating various elements of AI capabilities is quite constrained.

I have been working with UiPath for three years.

I find it to be highly stable.

Scaling on-premises can be cost-prohibitive due to the need to invest in hardware and infrastructure. This cost factor makes transitioning to the cloud a more attractive and well-designed option for scalability.

Our experience with their customer support has been excellent. We've encountered very few issues that required us to reach out, but when we did, we could contact our dedicated representative, and they efficiently escalated the matter, resulting in a prompt response from their support team. I would rate it eight out of ten.

Positive

We have experience with Microsoft Power Automate, but it's important to note that UiPath and Microsoft Power Automate serve different purposes and have distinct target use cases. This uniqueness is a critical factor that sets them apart from each other.

The initial setup process was quite straightforward.

We initiated the POC to test the viability and implementation of automation before expanding the environment. The setup was designed with the understanding that we required distinct test and production environments. It was initially developed as an on-premises solution and is now transitioning to a cloud deployment. We've had a lot of success with Lydonia Technologies as a partner.

We now have access to critical data, and the accuracy has improved significantly. Additionally, the time it takes for processes or submissions to go through has been reduced from three or four days to just one day. While the cost savings in terms of dollar values may not be substantial, the real benefit lies in freeing up employees to concentrate on more meaningful tasks.

I find the pricing to be reasonable, especially when compared to other offerings in the same market.

My advice would be to begin with a small-scale approach and construct your automation incrementally. While it might be tempting to automate an entire process in one go, it's more practical to break it down into smaller components. This way, you can adapt and refine each piece as you go, reducing the risk of issues arising or changes occurring before the entire automation is completed. 

Overall, I would rate UiPath eight out of ten.

We use UiPath to automate various processes across different functions within our organization including back-office operations, with a particular emphasis on finance, procurement, HR, and IT, as RPA technologies initially emerged from the finance sector.

Also, we extend our automation services to areas directly associated with production and supply chain operations.

Our primary goal is process automation, which lowers costs, enhances quality and improves operational flexibility. This is crucial due to our multi-time zone operations, requiring continuous processing. We're also dedicated to integrating various applications within the organization and addressing gaps. While engineering and IT departments have substantial automation, we're working on refining and addressing specific gaps in these areas.

The orchestration process itself offers a high level of impact, flexibility, and ease of development. While we have made significant improvements, particularly in terms of integrations and the seamless connection of integrators to applications, the process remains remarkably straightforward and efficient. It has significantly improved the accuracy of our operations, particularly in terms of quality, and has also reduced the time required.

There's room for enhancement, particularly in the support department and in the area of reporting, to provide a more robust product for gathering insights.

I have been working with UiPath for approximately five years.

The solution's stability is quite commendable and even when we encounter incidents, we consistently update to the latest versions. We typically lag about seven months behind the latest releases because it takes around three to four months for the new versions to stabilize after their initial release. I would rate it nine out of ten.

Scalability appears to be quite robust, especially when we have a solid model in place.

The improvement is needed for their support services. I would rate it seven out of ten.

Neutral

The initial setup was relatively straightforward. Back then, we were using a standalone automation suite. While we now have a cloud-based automation suite, the transition wasn't complex, and we found it quite easy to implement.

We've seen a positive ROI. Our organization, with the assistance of skilled consultants, successfully implemented the system and we established a robust business model and have maintained a centralized approach.

We evaluated several solutions available at the time, all of which were related to end automation. Ultimately, we opted for UiPath and that decision was influenced by the learning opportunities offered through UiPath Academy. At the time, it appeared to have the most compelling value proposition, with a strong ability to market and demonstrate the product effectively compared to other options.

The ease of use depends on whether you're a developer or someone who mainly uses automation. Nowadays, it is much more user-friendly compared to when I first started using it back in the day. The landscape has evolved significantly with a wider range of solutions available today and they've made substantial improvements, especially in terms of document standards.

Overall, I would rate it eight out of ten.