UiPath Reviews

We primarily use the solution for automation of the back office. When speaking about our customers and use cases, I wouldn't highlight one specifically, however, mainly, we are using UiPath to build a center of excellence. The aim is to automate a majority of the processes in the company, and that includes Order-to-Cash, HR, supply chain, and even IT, among others. We are not approaching needs for one or another specific process. We want to automate the enterprise end to end.

There are many great features in UiPath that our clients consider valuable. I definitely like Studio. The Studio's a very powerful product, which helps very easily to build automations. Nowadays, there's also a StudioX for citizen developers, which doesn't require coding.

Orchestrator, which helps users monitor and schedule robots, manage assets, credentials, et cetera, is also very useful.

The third feature worth mentioning, I would say, is Insights. It is reporting and dashboards. Once the robots are running, it is quite valuable to see how those robots are performing. You can see KPIs and other aspects of both robots and processes.

Worth mentioning is the Automation app, which helps to manage the automation initiative end to end, especially building the pipeline and collecting the ideas.

It is quite easy to build automations with UiPath, especially now that they are segregated depending on seniority, meaning that you have the regular Studio and Studio Pro, which are truly for developers, however, you also have StudioX, which is more for people without a previous coding background. That makes it quite easy to use. People with a business background find it quite easy to pick a tool up and use it in daily automation. They didn't have any previous experience with programming or making macros or whatever else, and still, they have no problem with UiPath.

UiPath enables users to build end-to-end automation, and this is what we are doing on a daily basis. UiPath enables mainly our clients (through us) to build end-to-end automation in their processes. When I mean end to end, I mean that we help them to automate the chain of processes and do not focus on the single practice itself.

End to end coverage within UiPath is a great advantage and offers great possibilities. It is really important to have the ability to do end to end. Though it is not applicable all the time, it still is a nice option to have and use when needed.

Very soon after starting the RPA journey, customers realize much more important benefits than time-saving itself and FTE saving or FTE reduction. There are things that happen, like quality improvement. Whenever the work is done by robots, it is running in a much more stable manner and without any human mistakes and errors. It is also sustainable, predictable work, meaning that robots do not get sick or have a bad day, or face conflicts with each other, et cetera. They just do their work. They also can’t get viruses, such as COVID which means that we don’t have to worry about losing staff.

We have a customer speech workload that was growing dramatically in relation to COVID and having processes already automated, it was very easy to sustain and even upscale the delivery. The customer experience is better as well. It is not only important to spend less time or fewer resources in delivering the service to the customer, it is also important that the customer gets a quick response. Overall, the customer experience can be much improved when using robots in the processes.

In terms of the Automation Cloud offering, UiPath handles infrastructure maintenance and updates to save time for our client's IT department. Having UiPath in a cloud enables enterprises and customers to focus more on the automation initiative itself, instead of managing all the hardware and dealing with all their hardware problems and having more or giving more time to the IT department. Instead, you can use everything out of the box from day one and focus on bringing benefits to your end customer or end employee.

The Automation Cloud offering has helped to decrease time to value from UiPath. I would say that Automation Cloud increases time to value dramatically in the sense that you can start from day one. Literally day one, you can go and start automating the processes without bothering with all the infrastructure topics. The time required to deliver the first benefits is reduced dramatically.

Automation Cloud’s offering helps to decrease the solution's total cost of ownership by taking care of things such as infrastructure maintenance and updates. It helps to reduce the cost of infrastructure maintenance, especially in the early stages of the projects, as well as on small and medium projects (for the long term). Not all customers or enterprises have strong IT departments or strong infrastructure in-house nowadays. Even large enterprises are moving more and more towards cloud services, even though they have strong IT infrastructure teams in place.

Automation Cloud is able to scale well due to the fact that we can, in a matter of minutes, or, in the worst case, hours, double the capacity. I would say that it positively and dramatically affects the scaling factor.

UiPath is a SaaS offering. It enables our customers to really quickly adapt and start using the technology almost from day one. It is very easy to start developing. It is very easy to start.

We are using UiPath Apps for our customers. However, this feature has not yet helped to reduce the workload on our IT department, or on our client's IT department by enabling end-users to create apps. Mainly, we are still involved as a service provider in the creation of the apps for the end-users. That said, where it brings added value is it reduces the limitations or the need to have an additional user interface, as you can create this app or user interface directly in UiPath to have an even better user, employee, or even customer interaction.

UiPath apps definitely increased the number of automations created. You can take more into the scope, what wasn't there before, with just attended or unattended automation, considering the fact that you can build a better user interface or any user interface from the very beginning. Before, there were only simple message boxes and prompts. Now, you can build really nice forms to interact with your end-users. It helps to accelerate initiatives.

Our teams have used UiPath’s Academy courses. Every team member of our company went through UiPath Academy. We always start with and actively involve UiPath academy.

UiPath Academy courses are a part of our standard onboarding procedure in the company, especially if we onboard junior developers. The very first thing we direct them to is UiPath Academy. Everyone starts with a basic foundation and goes through to a diploma and certification, and only then will we build on top of that more specifics about our standards, of our delivery approach, et cetera. I would say that UiPath Academy is a core and basic start for each and every employee in the company. Based on that education, we will later elaborate on different topics.

The biggest value I see behind UiPath Academy is its simplicity in terms of delivering the information. Even if you don't have any previous development experience and coding experience, all the explanations, videos, practical tasks, and reading material is formed in a way that is really easy to understand. The biggest value I see is its ability to bring people up to speed from really different levels, including very, very junior people with no previous experience in coding, programming, or the creation of robots.

UiPath's user community is excellent. Being an MVP, for me, the community has huge value in the whole end-to-end journey of RPA. Meaning that, at the very beginning, whenever you need to learn new things, you can always find a lot of useful hints in the forum and in the community. Later, when you already have delivered some solutions, you might face some problems. Luckily, very likely, you are not the first person to face those problems. There is always someone who already has had this problem and may have even raised it in a forum or on YouTube, et cetera. Even when you are already deep in delivery, sooner or later, there will be a point where you reach out for help to the community. The community, therefore, plays a crucial role for developers and automation specialists - be it business analysts, developer architects, et cetera. Having a strong community is definitely one of the most important factors that sets UiPath apart.

I'm not actively involved in other communities, and therefore wouldn't be able to compare UiPath to other similar communities. I can only say that the UiPath community is very supportive and very active in responding to any queries. The way it’s organized, it’s inspiring the next generation of forum members to help others and pay forward with insights based on the help they receive. UiPath’s community is really responsible and supportive.

In terms of reducing human error, at the very beginning, almost every company when starting the RPA and automation in Germany thinks of FTE saving as the main benefit. However, very quickly they recognize how huge the value is behind the quality improvements that happen after automation. It is quite obvious that robots are not doing human-like mistakes that may be caused by, for example, not paying attention or not getting enough sleep et cetera. Robots also cannot get bored. Very often, and whenever you have to process 1,000 or 10,000 records in more or less the same manner, it just becomes super repetitive. A mistake can appear in manual work as humans can lose focus on redundant tasks. This is not so when robots are involved.

In terms of time savings and error reduction, usually in our initiatives, we can see not higher than 5% of error rates when executed by robots. Even in those cases, I wouldn't say they are errors and more likely exceptions, which are documented and later handed over with specific explanations. A good KPI for our robots is to have less than a 5% exception rate. Related to this is that, by improving quality, we still save a lot of time as it can reduce the number of reworks which we might have afterward. For example, in one of the projects we were delivering, it reduced by eight times the amount of reworks or fixes, which the customer needed to process due to human-directed errors. Mistakes and fixes, therefore, were reduced by eight times.

What I would improve in UiPath, or I would just say, keep on improving, is the other products in end-to-end automation. UiPath started with Studio and Orchestrator as a core product, and still, we are actively co-operating UiPath and suggesting improvements for the other products. 

One of the products where I would definitely see a need for improvement would be a Task Capture. It is already good, however, there are many aspects and many ideas, which, for example, our business analysts have, which can be improved.

I've been using UiPath since 2016. It is already over five years. I'm familiar with the product.

Both on-prem and cloud solutions are very stable. The cloud is stable thanks to the UiPath team and on-prem, in our case, is stable thanks to our customer IT infrastructure team. Between the product itself and the infrastructure, be it Azure Cloud or on-site infrastructure, the stability is good. If there's any instability, it could be related to the people involved in using it as I've had a good experience with both cloud and on-premises stability.

The scalability of UiPath is one of the main competitive advantages, compared to other products. The software and the solution give you the opportunity to stably run it and scale it. With stable operations, you can focus on the new automation instead of maintaining already existing solutions. UiPath is very good at scaling in a friendly way and has good support that can help too.

I'd rate the solution at an eight out of ten. I never give ten, just to keep the motivation to improve high. I still believe that there are areas of improvement, though I really rate UiPath's support very high. The response time can always be shorter, the specification on solving problems can always be better, et cetera. Overall, I am extremely happy with the support UiPath provides in over 95% of the cases. For the remaining 5%, we still received the needed support, it only takes another iteration to move through another team and have a look at the problem.

Comparing the initial setup on cloud versus on-premise, the cloud configuration is much easier. This is one of the purposes of the cloud solution. It's meant to be easy to deploy and easy to scale. Documentation for the cloud is definitely straightforward. In terms of on-premise deployments, it is also quite straightforward, especially at the start, however, the complexity grows with the demands and requirements from the customer. If we have to get into the area of high availability and more of a complex server setup, it takes some effort to establish everything.

The simplest deployment on the cloud would take a matter of 15 minutes or maybe even as little as five. After five minutes you are ready to go and can use Studio and the cloud Orchestrator. It is very fast. You still need to have your admin rights available on your PC, however, that's the only prerequisite. 

For deploying on-prem, it's nearly the same for a simple deployment. If you only want to use the Studio and attend the job, it is very easy to configure in a matter of 15 minutes. Whenever you get into Orchestration, it will require more complex setups. It might take one or two days to set up, depending on how good of an infrastructure team you have to onboard.

The strategy in implementation remains the same no matter which deployment. In the end, you still have the same setup of products, be it Studio, Orchestrator, Task Capture, or whatever else. You have the same configuration of the products. It is only on the backend that is slightly different as it is hosted in another place. You don't really recognize the difference between cloud and on-prem hosted services.

At the very beginning, when we started the RPA journey, we were always tasked with understanding and looking at the potential return of investments. Therefore, we don't start automating the process before understanding the savings. For each and every process which we automate, we start with understanding what it will bring to the end customer. Even if we see minimal savings in the processes, we automate these. The biggest processes which we were automating were saving more than 20 FTEs (Full Time Equivalents). We are speaking to just about one process.

For us, FTE saving and time-saving are the same thing. It’s just different units of measure. You can measure it in people equivalent or in an hours per year equivalent.

The good thing about UiPath is that they are very active when it comes to listening to feedback. Every release incorporates some of this feedback into the product life cycle.

We are using both UiPath's Automation Cloud offering and the on-premise solution. We have customers, which need on-premise as well as customers which are running it in the cloud. On-premise, we have clients using different versions, however, it's my understanding that we are using version 2020.10.

I would definitely recommend, when starting the RPA journey, to start to use UiPath. Think about RPA as a robot factory, as a strategic thing, however, do not focus on one or another process. Think big and aim for automating all the manual processes in the corporation and from day one, and work to adjust all your procedures and infrastructure, the way that you've been able to get to this point. Do not get stuck at some point and feel you need to rework anything. Rather, change your standards in order to scale. In fact, aim for scalability from day one.

I'd rate the solution at a ten out of ten. We are a happy partner of UiPath and we have had many successful implementations with our customers. I can confidently say, after five years of experience using UiPath, that I've been happy with it. I still believe that there is always space for improvement. However, I really do have an appreciation for the tools. They're making a really good product and they should keep on improving at the same great pace. We plan to keep on using this product to deliver the same great services to our customers.

Currently, we are using it for reading emails. We download the attachments that we get in emails. After downloading those Excel sheets attachments, we process the data based on a few rules. The processed data is input into the SAP application. In the SAP application, based on the business rules, we process the data and commit.

It is very user-friendly in terms of building automation. We don't need to be experts in coding. We can learn it easily and build complex business tools in UiPath. We don't need prior coding experience.

It reduces the cost of digital transformation. Every day, we get 10 Excel sheets, and somebody has to sit and read the Excel sheet and load the data manually into the SAP application. Three to four employees are required for the same job, but if we automate this process, it can be done in a minute. It is easy, and we save time and cost.

It reduces the time taken for a task. If we are manually filling timesheets, we need to open the website, fill the timesheet, and submit it. It can take 10 minutes. With automation, it will take just a minute.

Orchestrator is very useful for deployment and publishing, maintaining queues, and running jobs.

In UiPath, REFramework is useful for different use cases with predefined code templates. There are well-established steps. There is a step for code marginalization. Similarly, there are separate steps for initialization and processing. For closing an application process, a step is there. So, it is very well modularized for getting the transaction data. If there is one exception or anything wrong happens with an application, it will log the exception in the orchestrator and send an email. It can also close your applications and end data processing. So, everything is well organized and separated, and we can log the exceptions separately in the queues as business exceptions or application exceptions. We can have the complete report of a particular queue.

For document understanding, there are so many features. I haven't used them practically, but to read a PDF, there are patterns and semi patterns. A wait option is also there for somebody to come and correct it. It can wait until somebody comes and corrects it, and then it will do the processing. So, all of the features are very useful in UiPath.

In exception handling, wherever exception occurs, the out arguments are not being passed. It would be good if there is a way to pass the out arguments. 

Sometimes, when an element is not there, UiPath gets stuck, and it doesn't even throw an exception. It stays stuck for hours until we go and check the logs. When this happens, we have to kill it. It happens in some cases, so an improvement is needed there.

I have been using this solution for three and a half years.

Other than the issues related to the exception handling and UiPath getting stuck, it is very stable.

It can scale well, but we don't really have a need to scale it. Currently, we are automating 15 projects. We are planning to use other functionalities of UiPath to automate extra things.

Currently, we have 1,000 people who use this solution. They are consultants, developers, and business analysts. A business analyst takes care of making design documents and solution documents. The RPA developers develop the code and test it. After that, for deployment, someone is there to take care of all technical things. After that, the support team is there to look after the deployment.

I didn't call UiPath support, but I know about them from my friend. We had called them for some issues, and they answered those very well. I would rate them a nine out of 10.

I have worked only on UiPath.

Its initial setup is straightforward. It is not that complex. We need to install UiPath Studio, and then we connect it to Orchestrator for getting logs, etc. It doesn't take more than an hour.

I took the help of my colleagues.

I'm not sure about licensing and pricing, but the pricing for their certification is a little bit more. Previously, we could do it for no price.

I would definitely recommend it to my colleagues and others. It is very user-friendly.

In terms of reducing human error, it is not up to the mark. It detects human errors, but it waits until we place the correct files for processing. For example, when comparing files, a human can detect two almost-similar addresses as the same, but a UiPath bot cannot do that. So, in some cases, it won't work as humans. It cannot decide. It works on predefined rules.

Considering its areas of improvement and the cost of certification, I would rate UiPath a nine out of 10.

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.