Level of Difficulty: Beginner – Senior.
Automation is becoming a hot topic in conversations about the fourth industrial revolution (4IR) and fifth industrial revolution (5IR). Automation is referred to as the use of technology to replace human labour or even work alongside people in some way, leading to some sort of benefits (or saving) of having automation implemented. Automation comes in different forms, shapes and sizes with a lot of emphasis placed on Business (or Digital) Process Automation (BPA/DPA) and Robotic Process Automation (RPA).
While RPA is focused on mimicking a person’s actions, behaviour and decisions, BPA and DPA are focused on automating business processes with specific focus on efficiency and optimisation. UiPath was identified by Gartner as a leading RPA technology in 2020 and 2021 with Microsoft also identified as a leader in the RPA in 2021. Microsoft are positioning Power Automate and Power Automate Desktop as a technology stack that enables citizen RPA development.
UiPath was founded in 2005 with their first desktop automation released in 2013 with Microsoft first releasing Microsoft flow (now known as Power Automate) late in 2016. Power Automate Desktop went into public preview in December 2020. UiPath definitely has the upper hand in maturity, in terms of the RPA offering, with Microsoft displaying much potential for growth.
In their immediate states, there are a few different comparisons that can be made between the two platforms when developing enterprise-level automation architectures.
Both UiPath and Microsoft have ensured that their automation offering forms part of a bigger picture. Microsoft has put together the Power Platform (comprised of Power BI, Power Apps, Power Automate as well as Power Virtual Agents) which integrates well into the rest of the Microsoft technology stack (from O365 right through to Azure). Microsoft has also made sure not to exclude any major third party technology stacks as integration points into the Power Platform.
UiPath have led their offering along a similar trajectory, ensuring that they have multiple products that allow developers to adequately develop artefacts throughout the hyperautomation lifecycle.
One of the similarities of both products is how each product is priced. Due to demand, usage, availability and complexity, pricing differs between each product, with some products being grouped together and others being offered with add-ons subject to different sub-levels of pricing as well. Some of the integrations and automation enablement technologies are compared across the technologies below. Each technology category is specified and the specific products are added in the appropriate columns to denote if that technology is catered for or exists within the landscape with specific reference to additional information added in the comments
|Process Understanding||– Task Capture|
– Process Mining
– Task Mining
|– Power Automate Desktop Recorded||UiPath offers three separate products which can be used to help identify and understand the requirements of a process. Microsoft has included a recorder in the Power Automate Desktop product to assist in recording the steps of a process|
|Data Entry/Forms||– UiPath Apps|
– Third Party Integration
|– Power Apps|
– Microsoft Forms
– SharePoint Lists/Firms
– Third Party Integration
|Microsoft has multiple mechanisms available that allow a user to enter data to be stored and used as part of the workflow/automation. UiPath has a specific product which is used to gather data to be used within or used to interact with the automation. Both products also allow for third party integrations, like K2, for example.|
|Data Storage||– Data Services|
– Storage Buckets
– Third Party Integration (like SQL Server, etc.)
– Third Party Integration
|Microsoft leverages their stack used for data storage. Some of those mechanisms also allow for file or document storage. UiPath also leverages their own products available for data and file storage. Both also utilise third party integration.|
|Monitoring||– UiPath Orchestrator|
– UiPath Insights
– Automation Hub
– Third Party Integration
|– Power Automate Cloud|
– Admin Center
– Third Party Integration
– Custom developed Power BI reports
|Monitoring solutions can become quite tedious in the Microsoft stack. For more specific visuals or monitoring, custom solutions would need to be created. With UiPath there are multiple mechanisms that allow you to monitor your processes with granular detail.|
|Test Management||– UiPath Test Suite|
– UiPath Orchestrator
– Third Party Integration
|– Third Party Integration||Microsoft does not yet have a defined Test Management portion of the automation offering. UiPath, however, have created a product (Test Suite), specifically geared towards enabling testing and test driven development. The UiPath platform, in its current state, is ready for test driven development as an approach. Microsoft is not quite there yet.|
|Document Processing||– UiPath Document Understanding|
– Various OCR technologies
– Third Party Integration
|– AI Builder|
– Azure Cognitive Services (including form recogniser)
– Third Party Integration
|Both products are capable of extracting information from documents. Both offerings come with additional costs.|
Each of the above offerings are subject to the proceeding sections.
In terms of functionality, UiPath definitely does have the upper hand when comparing the can’s and cannot’s between the UiPath and Power Automate (PA), in both cloud and desktop automation capabilities.
|Create Own Activities||Yes||No||UiPath allows for activities to be developed by the community and published for reuse by other developers. This has helped mature the eco-system significantly, in terms of functionality, and might slow down the progress of Microsoft getting to a more ‘stable’ place with some of the activities/actions.|
|HTTP Requests||Yes||Kinda but it depends…||HTTP requests are useful when using APIs which are way more reliable than front-end automation. This can be implemented from the cloud flows but it doesn’t allow for optimised development of flows. HTTP Requests also requires Premium licensing on Power Automate.|
|Convenient use of Try Catch blocks||Yes||No – Requires some fancy footwork||Although there is functionality on how to use ‘on error’ blocks, which are the equivalent of ‘try catch’ blocks on PA Desktop, using these are tricky because it still throws errors.|
|Global Exception Handler||Yes||No||A global exception handler in UiPath catches any error that is thrown and allows the developer to decide how to deal with these errors on a ‘per solution’ basis. This would come in very handy for any RPA tool, especially where front-end development is taking place and application exceptions can be unpredictable when change is introduced without prior notice.|
|Renaming of Activities||Yes||No||PA Desktop does not yet allow you to rename actions which makes identifying exactly which action failed really tedious, when looking at the errors returned by the Desktop flow, on the cloud flow.|
|Pin ‘on error’ next action to subflow or set variable||Kinda||Yes||PA Desktop allows a number of different options when configuring the ‘on error’ portion of a get element details or click activity. This is something that would need to be handled in a try catch statement on UiPath for most activities. Some activities in UiPath now allow you to configure ‘ContinueOnError’ as well as setting the output UI element which could be used as a ‘On Error’ check.|
|Scoped variables||Yes||No||All variables in PA Cloud and Desktop are ‘global’ and can be accessed from anywhere in the flow, the disadvantage is more memory usage, especially when storing elements with a lot of JSON data (for example). On the other hand, this supports motions presented in DoDAF architectures.|
|Set input and output variable type to anything other than text||Yes||No||This makes the use of booleans quite difficult.|
|Custom creation and control over variables (including type)||Yes||No||In PA Desktop, the variable creation is done as a result of an object or using set variable. The type is therefor, dependent on the result type.|
|Use Excel documents without Excel being installed||Yes||No||UiPath allows for a workbook to be referenced and used without the need for Excel to be installed. PA Desktop doesn’t allow for this yet. Hopefully it will soon to avoid additional licensing.|
|Built-in asset and credential management||Yes||Not really||UiPath allows for the storage of credentials and assets on the orchestrator. PA works best when storing credentials in Azure Key Vault which requires Premium licensing.|
|Built-in queueing mechanism||Yes||No||The UiPath orchestrator allows for queues to be created, with different triggers which allows for items to be queued for processing based on a multitude of factors, like priority, deadlines, etc. The Power Platform does not have this built in natively yet and requires Azure resources to assist with this (resulting in Premium licensing).|
|Bulk processing items in Excel||Yes||No||UiPath allows for the manipulation of Excel data in ranges, meaning that more than one row can be inserted, deleted or updated at the same time. The Excel connector on PA Cloud only allows CRUD on a ‘per row’ basis which is not at all optimal when processing larger files. For time optimisation, different solutions will need to be investigated, like using an Azure Function or some other storage mechanism. Possibly even the extended use of formulas.|
|Trigger a process when receiving an email||Yes||Yes||UiPath makes use of Integration Services to trigger processes in a similar fashion to Power Automate Cloud flows.|
|Edit selectors or elements of UI Automation||Yes||No||UiPath allows you to turn selectors into dynamic selectors, making them reusable and less specific. PA Desktop only allows you to add elements as they are and cannot be edited. Getting these elements set up can be more tedious when using PA Desktop than UiPath as ERPs, like SAP (for example), requires more configuration and access than UiPath does as PA Desktop needs transactions to be executed.|
|Level of restriction||No||Yes||Power Automate does not allow for a depth of more than 9 levels of scope, loops and conditions which makes sense in terms of performance but without the use of sub-flows (like invoking workflows in UiPath), this becomes difficult to manage on more complex flows on the PA Cloud flows.|
|Access log runs||Yes||Kinda||So to access logs automagically, you need to use some PowerShell. It’s not as easy to access as using an API or database (if the UiPath orchestrator is on-prem).|
|Detailed time execution of each step||No||Yes||PA allows you to see how long each action took on the cloud flows run history. To do this with UiPath, you’d need to write some custom logging and calculations.|
|Decision to upgrade packages and rollback to previous versions||Yes||No||It would be useful to be able to rollback to previous versions of connectors when there are bugs that occur which breaks something that was previously working.|
In terms of the ease-of-use and implementation of different automation categories and capabilities, Power Automate maintains the upper hand for integrations with the Microsoft stack and ecosystem while UiPath maintains the upper hand for categories that make use of more ‘custom’ types of automation.
|Integrated Data Storage||X||X|
|Reporting Capability||X – Capture/Structure||X – Visualisation|
|Data Capture Application Integration||X|
|Microsoft Teams Integration||X|
|Microsoft Outlook Integration||X|
|Microsoft Graph Integration||X|
Power Automate is really powerful when you’re building an integration flow that contains a few actions which use a small number of connectors (between 1 and 5) that encapsulate quick and easy-to-use API calls. As soon as the flow is expected to deal with a few additional business rules or process steps, the platform loses efficiency. The more actions are used, the slower the flow takes to load (especially when trying to debug historical runs). UiPath maintains the upperhand when developing more complex solutions. It is much easier to build modular components and bring them all together using UiPath. Developing a solution in modules can reduce development time. Waiting for a platform to respond can have a drastic affect on development time. It is easy to get distracted, as a developer, waiting for a flow to load or to run a test.
|Feature||UiPath||Power Automate Cloud||Power Automate Desktop||Comment|
|Unit Testing||X||X||UiPath allows you to create sequences and workflows in units which can be invoked within the main workflow. It is difficult to effectively invoke subflows in PAC, especially taking licensing implications into account.|
|Debugging||X||X||UiPath allow developers the option to debug or run a solution which allows the developer the ability to either fast track the testing process by running the process, while watching the logs or debugging each step of the solution run through debug mode. UiPath allows the developer to debug activities, workflows and sequences in units, which speeds up the testing and development process. Although PA Desktop allows for the ‘Run from action’ functionality, it is not available on PAC.|
|Realtime Logging||X||UiPath allows for information to be logged at different levels (like trace, verbose, information, warning and error) while PAD and PAC only displays warnings (more common on PAC) and errors. By allowing developers to monitor logs as the flow runs, it is easier to determine which steps have been successfully passed and which steps the process might be stuck on.|
|Developer UI Experience||X||X||It is tedious to work on PAC in a browser window because the platform responds differently between browsers. Sometimes browsers crash and all work is lost. One cannot save the flow if there are errors. Commenting out (or disabling) code is not yet allowed on PAC, however, there is a work around available. This is not efficient as it could allow developers the ability to save their work more frequently. |
The copy and paste functionality on PAC is buggy and doesn’t always work.
The above two points are not applicable in UiPath
When referring to the User Interface Application Creation within both platforms, we compare UiPath Apps to Microsoft Power Apps (and in some cases, Microsoft Forms). These applications are typically created when working with data that needs to be created, read, edited or deleted by users before being used or integrated with proceeding automation processes. In some cases, the user interaction with the apps actually triggers an automation process.
|Feature||UiPath Apps||Power Apps||Comment|
|Data Capture App Development||X||Microsoft Power Apps allows for a significant amount of customisation. Creating a stock-standard CRUD (create, read, update and delete) application using Power Apps is relatively simple and can be done in a few clicks. The alternative to this in the Microsoft stack would be to use Microsoft Forms which has much more limited functionality and only works with very basic tasks.|
UiPath Apps has less customisation potential and also comes with a few bugs but it is a huge improvement from previous versions which is a lot easier to use for citizen developers.
|Data Capture App Rollout||X||Although UiPath Apps is easier to use when creating basic apps, the licensing model for UiPath Apps makes the rollout across an organisation very difficult. Licensing models are a huge point of contention within both organisations, with a lot of focus being placed on them but they do pose very real obstacles within an environment and these should be taken into account in the design phase of the solution.|
UiPath and Power Automate both have different kinds of monitoring available to developers and operational support. The variety of monitoring tools and mechanisms made available by UiPath have the advantage over the mechanisms provided by the Power Platform as they allow for monitoring automations in finer detail.
|View exactly which item failed||Yes||Yes, but it is tedious to monitor flows on solutions with high volume||Although Power Automate does allow for flows to be monitored from the monitor tab via the online portal, it would be very difficult to track exactly which items had issues, especially when desktop flows are called from the cloud flow where the desktop flows have quite a lot of exception handling built in. The Monitor tab does allow you to view failed cloud flows as well as monitor desktop flows but linking the cloud flow that triggered the desktop flow is tricky.|
|Monitor realised benefits and savings||Yes||No – Not without custom dev||This can be managed in multiple ways. UiPath offers this level of monitoring as part of the UiPath Insights and Automation Hub offerings. Both require additional licensing, however, the option is available.|
|Monitor process logs||Yes||Yes, kinda||UiPath allows for logs to be viewed at different levels while the process is being executed in UiPath Studio as well as the UiPath Orchestrator. UiPath queue items also store individual logs where queue items are processed. Information level logs may be used to log information as the process is being executed.|
In order for this to work for Power Automate flows, one would need to write a custom logging solution which would affect any per user flow licensing plans in cases where these logs are called from the cloud flow.
The scalability of a solution should be monitored and compared on a case-by-case basis. Microsoft recommend creating multiple flows or processes to better manage scalability, whereas UiPath take a different approach by segregating a process on a queue item level where one process can execute multiple items in a single execution run. In the table below, X denotes the recommended technology for each feature listed below:
|Cost||X||Scaling solutions in UiPath is cheaper than in Power Automate as licensing remains mostly the same. The impediment on cost, when using UiPath, is introduced when additional infrastructure is needed or when additional users need to be licensed. In cases where Document Understanding units are fully utilised, additional credits may be purchased from UiPath. This would also be the case when AI builder credits are finished.|
Power Automate requires additional licensing when a solution is scaled. It is important to understand exactly to what extent the solution needs to be scaled when architecting the solution as any technical debt would impact the solution licensing and costing. Additional API calls would need to be purchased when using a per user plan. In a case where multiple instances of the flow need to be created, each flow would need to be licensed on a per flow plan. There are limits on the number of processes that may run concurrently.
|Additional Resources for Optimisation||X||In order to reduce run time and enhance performance/processing time, Azure resources (like Azure Functions) may need to be used to assist in scaling the solution in an optimised fashion when using Power Automate. Although scripts and code blocks may be incorporated into UiPath solutions, it is not necessary for additional resources to be used in such solutions to optimise the solution.|
In terms of cost, Power Automate maintains the advantage in cases where the scope is small and is inline with (only) integration tasks. As soon as the scope becomes more complex and the solution needs to scale, the cost starts to increase. The licensing options for Power Automate vary based on the scope of the solution design. The two main options are a per user plan or a per flow plan. Each have their own limitations. A per user plan has a limit of API calls that can be made from the flow per day which impedes on large scale solutions. Additional API calls may be purchased from Microsoft. The per flow plan only allows one flow to be created which means that for scaled solutions where you need multiple flows to run in parallel (due to concurrency processing limits), additional flow licenses would need to be purchased.
UiPath maintains the advantage of enterprise level where multiple processes are developed and orchestrated within the environment. The UiPath Orchestrator is expensive and incurs a large annual cost. When that cost is distributed across multiple processes, there is a closer movement towards realised savings.
Based on the above, the cost recommendation for this solution is summarised below, with X denoting the recommending technology for each category:
|Long term cost – not scaled (including apps)||X|
|Long term cost – not scaled (excluding apps)||X|
|Short term cost – not scaled||X|
|Long term cost – scaled (including apps)||X|
|Long term cost – scaled (excluding apps)||X|
|Short term cost – scaled||X|
Licensing comparison has been done in a separate post, accessible here.
Based on all of the comparisons addressed in this post, the table below provides a summary on the recommendations below:
|Ease of use||X|
|Long-term cost (excluding apps)||X|
|Long-term cost (including apps)||X|
As seen by the table above, UiPath has the advantage in all of the categories observed above. Power Automate will render a short-term cost saving in non-scaled solutions. In a case where multiple processes will be built, using UiPath would be a suitable solution. It is important to note that Power Automate and UiPath (among many other automation technologies) may co-exist in the same automation ecosystem in ways in which they could compliment each other. Please note that some of the above aspects may be improved by either (or both) vendor(s) in the future which may change the recommendation, however, at the time of recommendation, this is how the two technologies match up when compared with one another. These recommendations are based on the lessons learnt from our previous experiences with UiPath and Power Automate implementations.
Power Automate adds the most value when utilising the licensing models that are already in use within an organisation to build automations that do not require additional (or premium) licensing and more importantly, do not exceed any limits imposed by additional licensing (like scaling flows that are licensed on a ‘per user’ plan). There are multiple ‘basic’ templates that allow for quick and easy automations and integrations. Power Automate Premium licensing allows solutions to be built with more advanced capabilities. Although Power Automate solutions are scalable, doing so can be quite tedious. The Power Platform does allow for multiple licensing options.
UiPath adds the most value in an environment where an automation eco-system is being formed to cater for enterprise-level solutions that should be easily scalable. The UiPath offering includes a wide range of products that supports their matured automation and hyperautomation lifecycle. There are multiple licensing models available for the offerings provided by UiPath.
There is a lot of value that can be gained by implementing a hybrid approach to automation where UiPath and Power Automate are used, in conjunction, to provide powerful integrations and automations within an organisation’s Automation Center of Excellence (CoE). Both technologies have a lot of potential, with exponential growth predicted within the next few years. Each have their own benefits and shortfalls which make them competitive in their own ways.
Apart from the licensing aspects, the functionality, ease-of-use and implementation observations are also applicable to Azure Logic Apps.
Please note that all of these were findings captured at a specific point in time and may have been improved since the post was published.
4 thoughts on “[Automation] A Comparison Between UiPath and Power Automate”
Great article. While you mentioned UiPath doesn’t provide manipulation with O365 like OneDrive and SharePoint I would look at our marketplace where it shows that they do in fact have automation activities and connectors to integrate. https://marketplace.uipath.com/listings/microsoft-office-365-669054
Thank you for providing the link Michael. You are correct, UiPath definitely does integrate with O365. The content of the tablet only aims to illustrate that it is easier to manipulate content on OneDrive and SharePoint using Power Automate. It definitely is possible with UiPath, it just requires a little more pre-work, like creating app registrations (in certain cases), etc. I’ve covered Outlook integration in this post here for anyone interested: https://thejpanda.com/2020/01/27/rpa-using-the-microsoft-office-365-activity-for-sending-emails-in-uipath/
I hope to cover SharePoint and OneDrive in future blogposts.
Very useful article, thanks
LikeLiked by 1 person