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.
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.|
|HTTP Requests||Yes||No||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||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 involved.|
|Renaming of Activities||Yes||No||PA Desktop does not yet allow you to rename activities which makes identifying exactly which activity 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||No||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.|
|Scoped variables||Yes||No||All variables in PA 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 do not have this built in natively yet and require 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||No||Yes||UiPath processes would need to troll a mailbox for changes, whereas the cloud flows are triggered when a new email is received. This is true for most connectors on the PA Cloud stack.|
|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.
|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
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. There are multiple ‘basic’ templates that allow for quick and easy automations and integrations. Power Automate Premium licensing allows more 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 and 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.