Before using this solution, people would get those emails and the recipient had to download the file and then manually put it into SharePoint. We use it wherever we have workflow processes in which Microsoft products are interacting. It is very good at working with those simple Microsoft-product-related processes.

Those are the sort of things we can automate with Power Automate. From there, some other automation gets triggered and the file is processed in a certain way. There are certain times I will get specific Excel files from a pre-determined output which I have to always place into a particular SharePoint folder. For example, suppose I get my email with Outlook. We can automate to improve productivity and for those applications and simple tasks, it is easy to use. The reason why we are using this product is that we like to use it where we have automation projects specifically for Microsoft products. So some of it is actually reading the webpage, taking information off of the webpage, and doing things with it. We're trying to automate some of that process to link the systems together. There are some very long processes that are happening now, where we need to move data from one system to another and do some analysis, and all of that. I run a clubby cloud system for moving data back and forth. What I'm actually doing is interacting with actual systems. So it's a desktop piece that I'm actually using and that's definitely on-premise. Microsoft Power Automate is on-premises because I'm using the Power Automate Desktop. That's kind of why I'm not quite ready to publish because I'm not an expert yet, but I am actively working on it. I haven't found my way out of the snags as yet.

I've actually started creating some bots. It's a pretty big learning curve with Microsoft Power Automate and I'm trying to do a couple of other things.

Schedule power automate desktop