Microsoft's low-code strategy paints a target on UIPath and other RPA companies

For starters, my company's business people are not curious. This is not necessarily bad, but curiosity is a powerful accelerator for programming and automation tools. They weren't impressed nor motivated to adopt and extend the example flows. In the end, I had programmers creating flows for business people to use, and it was frustrating for the programmers and an uncertain black box for the business people. We even managed to create custom connectors to simplify a few flows. It failed and we gave up.

Regarding the specific tools of the "Power Platform", Power Automate has a horrible UI. It's slow, clunky and buggy. Sometimes you try to save your flow and it will give you a weird error. Then you refresh the page, the flow remains exactly the same, but now saving works. It's messy.

Power Apps has a bizarre billing/licensing issue. The idea behind the product is appealing, but when you start using it, it's a weird mix of a no-code design app with some legacy Microsoft Dynamics app. User management is confusing and tied to Dynamics. "External" users will cost you a lot more in licensing. You keep bouncing between old Dynamics pages and newer Power Apps ones. Even if you want to pay for the highest tier, it's incredibly difficult to find out how to do it. And if you don't pay for the highest tier upfront, Microsoft will create limitations for you on every corner (like accessing a database or using a given widget).

I didn't have any motivation left to try Power BI, but one of my interns told me that a _viewer_ of my dashboards would also need a license to have access to it.

I won't revisit these tools anytime soon.

it is ironic that you bring up Access because that is one the tools I despise the most, our helpdesk is routinely indated with requests from people that pass around Access Databases with custom data links either to Excel files, or ODBC connections that are not standard but rather customized by the "power user" that created the database, then they share the database and it generates all kind of errors that the non-power user can not fix so IT gets roped into spending our time fixing not only users system to establish the needed data links, but also moving things around and reconstructing the databases so it actually works in way that is shareable

The IT Dept has also spent countless hours correcting Access Database connection issues, and schema issues when we move servers, upgrade platforms, or do anything on the prod system that end up breaking the Excel and Access "Low Code Applications" that consume data from these services because the end user lacks the technical ability to fix them often because they were created years ago by people that have left the company or retired.

The thing is, until very recently, Bot Framework was the only game in town for Teams.

Doing something as simple as sending an outbound message to a user from a bot, if the user didn't initiate the conversation, was stupidly convoluted.

There's some stuff added to Graph API for sending messages now, but on the whole, the development experience is very, very far from what I would expect from Microsoft.

There's still no good way to sign in on behalf of a user to Teams, which makes writing load-testing tools to test a Teams bot a PITA - you can use Direct-Line, but then it isn't really testing how the bot would act against Teams...