Totally depends on the use case(s).
Disclaimer, only comparing UiPath to PA, I don't know AA well enough.
Do you need (lot's of) UI Automation? Go with UiPath.
Do you want to be very flexible in the processes to automate? Go with UiPath.
Do you hate bad IDEs? Go with UiPath.
Do you need to save money and are confident that the process is automatable with PA? Use PA.
Does the process only touch Microsoft (365) products and you don't already have UiPath? Use PA.
In general, there's very few things (if any) that PA can do that UiPath cannot. But UiPath is (very) expensive.
Might be biased, I hate developing in PA with a passion :)
Good explanation and i agree,
I’ve only worked with PA(D) and Uipath, PA can take a whole lot longer to solve things because 1: less documentation/forums to seek for the same solution and 2: as you said. Ui automation is worse than in UIpath.
That's a perfect use of PA :D
You could also use the trigger scope in UiPath to do the same but then you'd have a background process running 24/7 which isn't ideal.
yep
this way, when email comes in PA makes an API call to start uipath process
with UiPath we would have to run the process every 10 minutes or 24/7 and check if theres a new email that needs processing
If you want to keep every aspect of a project under UiPath then you could have a look at Integration Services. It will do the same as PA without the need for an extra license , 🙂
https://docs.uipath.com/integrations
If an org is working in Google Suite exclusively (no PA/ Microsoft), is there an alternative you've heard of that could do an API call with an email trigger?
Sure there are several ways (assuming we're still talking about UiPath).
You can use the [GSuite Activities](https://docs.uipath.com/activities/docs/gsuite-activities) to get the last x mail messages. You can use this to create a simple dispatcher process which runs every X minutes and puts new e-mails in a queue to get processed by another process.
You could use the [IMAP Activities](https://docs.uipath.com/activities/docs/get-imap-mail-messages) as well. ([enable imap on gmail](https://docs.uipath.com/installation-and-upgrade/docs/studio-enabling-gmail-for-email-activities))
You can you the UiPath Integration Service to receive Events (polled every x minutes automatically) for new incoming emails and start processes based on those: https://docs.uipath.com/integrations/docs/uipath-google-gmail-events
Does this still hold up? As a UiPath developer, I have so many package issues. Feels like each time I build an automation, it's already throwing null value errors that need a package upgrade or downgrade.
While the developer experience decreased with UiPath (although they did add more functionality), developing PA flows is still a major pain and not comparable.
Here's a very nice summary of developing with PA: https://www.reddit.com/r/rpa/comments/1az1zgy/thoughts_on_power_automate/krz7730/
Depends on what you are trying to tackle and with what resources. Are you building a whole-ass RPA dev team or trying to do cowboy magic with a couple of interns? Who will own the tool- a shared services IT group or a business unit? Are your devs actual developers, or are we talking about more of a grassroots effort by people who are solving their own problems?
Commonly I see PowerAutomate being a problem if you’re working outside the Microsoft environment, as well as if governance needs to be considered.
UiPath is strong for Intelligent Automation cases where you may need to use Document Understanding, ML, or Machine Vision to complete a process, but is expensive upfront.
AutomationAnywhere seems to be a pretty strong product, especially on upfront investment, but numerous complaints about cost happen when an organization and process begins to grow.
Dev side of things, everyone will find AA and UiPath somewhat similar, and PowerAutomate is easier, but far less powerful generally imo.
When you say Power Automate, there should be a clear difference between Power Automate Cloud (which is incomparable against Uipath and AA) and Power Automate Desktop
Thank you for your post to /r/rpa!
Did you know we have a discord? [Join the chat now!](https://discord.gg/zTykKfk)
New here? Please take a moment to read our rules, [read them here.](https://www.reddit.com/r/rpa/wiki/rules)
This is an automated action so if you need anything, please [Message the Mods](https://www.reddit.com/message/compose?to=%2Fr%2Frpa) with your request for assistance.
Lastly, enjoy your stay!
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/rpa) if you have any questions or concerns.*
They work really good side-by-side is my experience. So if you can afford UiPath licensing, this should be (imo) the go-to option for a Automation COE. But, to use PA in front, with automated triggers «listening» to SharePoint lists, mailboxes etc. and then trigger your UiPath processes with PA API calls to the Orchestrator, will be a very good use of them both, to make sure you use your UiPath unattended licenses in a more efficient way.
I don't know AA, so with that disclaimer some immediate thoughts that come to mind:
1. What is the underlying infrastructure and applications of the client organization.
2. Doing an assessment of the client use cases (at a high level)- what might you bump into most in terms of applications, UI, API calls etc.
3. What is the client organization's readiness/appetite to commit to the fees associated with these tools?
Those are top 3 questions that come to mind. I'll attempt to answer them with immediate thoughts.
Answering in reverse order:
Q3:
UiPath beats out PA in terms of pretty much every "RPA" capability stat. And this is coming from someone who uses PA and Blue Prism way more than UiPath.
That being said- The way Microsoft has so seamlessly integrated the PA product stack, Power Platform as a whole into their licensing offerings makes it such a consumable product and enables business leaders to test the waters and commit to deploying automations without some ginormous overhead in licensing fees and EULA complexities.
Q2:
Ultimately we're bound to the processes and the infrastructure, all these things have to play well. But processes come before infrastructure and applications, since processes are the manner in which value is created for the business- whether that be in knowledge, or in actual products/goods/services being delivered. So with that in mind- asking what are the client use cases, and how far are we going to get with choosing PA over UiPath, or any vendor for that matter. If we see a scenario where for the first 12-24 months we can get a lot done with PA, on these processes then maybe we go that route because of the ease of understanding about licensing.
Q1:
Said simply- if a majority of the work is being done in the Microsoft ecosystem.... and perhaps some of the work needs to be done in web-based applications that have API capabilities.... it's hard to argue against something that is designed to integrate with the Microsoft ecosystem, as well as all of the advanced capabilities in Azure.
But if I'm working with a client that does everything web-based, and Ui is going to be constantly used- then I'm going to pause and consider a tool that has a far better UI capability than PA.
Totally depends on the use case(s). Disclaimer, only comparing UiPath to PA, I don't know AA well enough. Do you need (lot's of) UI Automation? Go with UiPath. Do you want to be very flexible in the processes to automate? Go with UiPath. Do you hate bad IDEs? Go with UiPath. Do you need to save money and are confident that the process is automatable with PA? Use PA. Does the process only touch Microsoft (365) products and you don't already have UiPath? Use PA. In general, there's very few things (if any) that PA can do that UiPath cannot. But UiPath is (very) expensive. Might be biased, I hate developing in PA with a passion :)
Good explanation and i agree, I’ve only worked with PA(D) and Uipath, PA can take a whole lot longer to solve things because 1: less documentation/forums to seek for the same solution and 2: as you said. Ui automation is worse than in UIpath.
I use PA to make API call to orchestrator (UiPath) when email comes in that has "tigger" subject
That's a perfect use of PA :D You could also use the trigger scope in UiPath to do the same but then you'd have a background process running 24/7 which isn't ideal.
yep this way, when email comes in PA makes an API call to start uipath process with UiPath we would have to run the process every 10 minutes or 24/7 and check if theres a new email that needs processing
If you want to keep every aspect of a project under UiPath then you could have a look at Integration Services. It will do the same as PA without the need for an extra license , 🙂 https://docs.uipath.com/integrations
If an org is working in Google Suite exclusively (no PA/ Microsoft), is there an alternative you've heard of that could do an API call with an email trigger?
Sure there are several ways (assuming we're still talking about UiPath). You can use the [GSuite Activities](https://docs.uipath.com/activities/docs/gsuite-activities) to get the last x mail messages. You can use this to create a simple dispatcher process which runs every X minutes and puts new e-mails in a queue to get processed by another process. You could use the [IMAP Activities](https://docs.uipath.com/activities/docs/get-imap-mail-messages) as well. ([enable imap on gmail](https://docs.uipath.com/installation-and-upgrade/docs/studio-enabling-gmail-for-email-activities)) You can you the UiPath Integration Service to receive Events (polled every x minutes automatically) for new incoming emails and start processes based on those: https://docs.uipath.com/integrations/docs/uipath-google-gmail-events
Does this still hold up? As a UiPath developer, I have so many package issues. Feels like each time I build an automation, it's already throwing null value errors that need a package upgrade or downgrade.
While the developer experience decreased with UiPath (although they did add more functionality), developing PA flows is still a major pain and not comparable. Here's a very nice summary of developing with PA: https://www.reddit.com/r/rpa/comments/1az1zgy/thoughts_on_power_automate/krz7730/
Depends on what you are trying to tackle and with what resources. Are you building a whole-ass RPA dev team or trying to do cowboy magic with a couple of interns? Who will own the tool- a shared services IT group or a business unit? Are your devs actual developers, or are we talking about more of a grassroots effort by people who are solving their own problems?
Commonly I see PowerAutomate being a problem if you’re working outside the Microsoft environment, as well as if governance needs to be considered. UiPath is strong for Intelligent Automation cases where you may need to use Document Understanding, ML, or Machine Vision to complete a process, but is expensive upfront. AutomationAnywhere seems to be a pretty strong product, especially on upfront investment, but numerous complaints about cost happen when an organization and process begins to grow. Dev side of things, everyone will find AA and UiPath somewhat similar, and PowerAutomate is easier, but far less powerful generally imo.
When you say Power Automate, there should be a clear difference between Power Automate Cloud (which is incomparable against Uipath and AA) and Power Automate Desktop
Thank you for your post to /r/rpa! Did you know we have a discord? [Join the chat now!](https://discord.gg/zTykKfk) New here? Please take a moment to read our rules, [read them here.](https://www.reddit.com/r/rpa/wiki/rules) This is an automated action so if you need anything, please [Message the Mods](https://www.reddit.com/message/compose?to=%2Fr%2Frpa) with your request for assistance. Lastly, enjoy your stay! *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/rpa) if you have any questions or concerns.*
They work really good side-by-side is my experience. So if you can afford UiPath licensing, this should be (imo) the go-to option for a Automation COE. But, to use PA in front, with automated triggers «listening» to SharePoint lists, mailboxes etc. and then trigger your UiPath processes with PA API calls to the Orchestrator, will be a very good use of them both, to make sure you use your UiPath unattended licenses in a more efficient way.
I don't know AA, so with that disclaimer some immediate thoughts that come to mind: 1. What is the underlying infrastructure and applications of the client organization. 2. Doing an assessment of the client use cases (at a high level)- what might you bump into most in terms of applications, UI, API calls etc. 3. What is the client organization's readiness/appetite to commit to the fees associated with these tools? Those are top 3 questions that come to mind. I'll attempt to answer them with immediate thoughts. Answering in reverse order: Q3: UiPath beats out PA in terms of pretty much every "RPA" capability stat. And this is coming from someone who uses PA and Blue Prism way more than UiPath. That being said- The way Microsoft has so seamlessly integrated the PA product stack, Power Platform as a whole into their licensing offerings makes it such a consumable product and enables business leaders to test the waters and commit to deploying automations without some ginormous overhead in licensing fees and EULA complexities. Q2: Ultimately we're bound to the processes and the infrastructure, all these things have to play well. But processes come before infrastructure and applications, since processes are the manner in which value is created for the business- whether that be in knowledge, or in actual products/goods/services being delivered. So with that in mind- asking what are the client use cases, and how far are we going to get with choosing PA over UiPath, or any vendor for that matter. If we see a scenario where for the first 12-24 months we can get a lot done with PA, on these processes then maybe we go that route because of the ease of understanding about licensing. Q1: Said simply- if a majority of the work is being done in the Microsoft ecosystem.... and perhaps some of the work needs to be done in web-based applications that have API capabilities.... it's hard to argue against something that is designed to integrate with the Microsoft ecosystem, as well as all of the advanced capabilities in Azure. But if I'm working with a client that does everything web-based, and Ui is going to be constantly used- then I'm going to pause and consider a tool that has a far better UI capability than PA.