Power Automate Service accounts / Let users interact with data they have no rights to

The beautiful part of the Power Platform is truly that it is actually DIFFICULT to decouple who is using the application from what that user has the rights to do within the various systems they connect to.  The big focus of this platform has been to make it easy to let people work w/ data, while also tracking that they are doing so.  However, it is stupid-simple (if not exactly obvious at first glance) to grant a PowerApp user the ability to connect to data they otherwise couldn't.

Quick Fix

Let me just jump straight into it for those who are searching for a solution.  If you create a Power Automate flow now from inside a PowerApp (or via http:/make.powerautomate.com) you can alter any Connection used to use an account other than the end-users.  

By default, Power Automate flows called directly from Power Apps run as the end-user who is running the Power App.  To change this click on the Power Automate flow in question to view the details of the flow.  Then look to the lower-right for Run Only Users:

If you click on Edit here, then you will find the conveniently hidden option to change what each Connection uses to authenticate:

If you click on this drop-down, then you can select from any account that you, the author/editor, has the rights to.  

I'll leave it to the less-trustworthy tricksters to convince their CEO to run a Power Automate Desktop script to get them to authorize someone else to connect to their Outlook mailbox...

Why not do this for everything?

The technical reason

Well, again, the beauty of this platform is that it allows end-users to interact w/ only the data they have the rights to.  There are tons of benefits to seeing which users edited which rows/values in a SharePoint or Dataverse list vs. your service account.  It creates a very clean audit trail for legal purposes or just to smack someone for doing something boneheaded.  When we obfuscate this through a service account, we have to go to extra steps to ensure we're capturing who is making changes or accessing data that we don't normally have to do.

As well, Microsoft seems to have a bit of snit regarding the usage of service accounts.  If you're thinking they're being evil and trying to avoid people dodging licenses, then you're probably not wrong.  But, I am more inclined to think that they are being evil in wanting to track everything an end-user is doing.  The licensing evil seems more 1990's to me, where the big-brother evil fits our modern workplace.

The philosophical reason

On a more personal note, I also believe that not using service accounts helps remind us that employees matter.  Because if I leave my employer (don't get nervous people - I'm not leaving - or maybe that's a reason to be nervous), there should be some level of work required when I skip out the door.  As long as I'm not also the sole Domain Admin over things, people can access the work I've done.  Even if I don't share it with others.  And having had a long career that occasionally resulted in helping reduce headcount, I believe organizations need to have some mild incentives to remind them of the costs of losing staff.

Personally, I feel that service accounts hide turnover.  This lets organizations do this w/o any technical ramifications.  At this point in my long career, I'm not inclined to help hide the impact of turnover within an organization.  Turnover becomes a problem when we make it easy for all parties.

I wonder why we keep having these metrics around turnover in my current organization...

When to use them in the Power Platform

Lookups

I do still feel like there are valid reasons to use these within the Power Platform overall.  Widely used common lookups for example (Email -> EmployeeID).  Sometimes people get testy over crosswalks of what does/doesn't constitute restricted information.  Sharing a view-only list of 40,000 employees and their Email/IDs might not be something that an organization wants to expose to an easily downloadable Excel sheet.

However, Exposing that same lookup through a Power Automate script where you have to know one to get the other might be much more easily digested by a security team

Large Organization-wide service apps

If you're dealing w/ a 20 person organization, then it's pretty easy to manage the security rights to a SharePoint resource even when everybody needs to access some part of it.  When you're dealing w/ 40,000 people, slightly less so.  And while SharePoint and Dataverse have strong abilities to nail down some very granular security access, you might not have the staff to do so.

As we see PowerApps and Power Automate move out into the business, less database-centric viewpoints will dominate deployments.  Just because you can build an app doesn't mean you understand the SharePoint security model (even with/without simplifying/confusing it all by laying Teams on top of it).  In some cases, simply the # of users will force an app developer down the road of using a service account and putting the security into the app itself.

Large lists in Teams

If you've made the "error" of creating a Team for your project (duh!) and then putting your lists inside that team to simplify security (duh!) and then populating your lists w/ an amount of data that Microsoft says they support (30 Million rows?  Really?  Have you talked to the SharePoint Online team or read any screen warning you of having >5000 rows?), then you might encounter the issue where you cannot change security AFTER you populate out your list if it is too large.

This means that if you need to adapt your security to include row-level for anything, or only for certain rows, then you're trapped.

HOWEVER, you can leave your security model the same and still allow extending this out to a more customized experience if you route these requests through Power Automate and a service account.

Final Thoughts

The fact that this feature is hidden inside Power Automate instead of very easily exposed via the Connections within the app itself should remind you that Microsoft isn't excited when we do this.  So be cautious in how you implement this.

If you feel like you're going to sneak around some kind of licensing gotcha here, just remember that the entire platform is tied into the big-brother aspects of Teams and the Graph API.  While Microsoft is being nice about this today, don't believe this will go on indefinitely.  So be careful banking your future on this kind of workaround.

I also believe you should consider using the PowerApps (V2) trigger for any Power Automate script you use for these.  Mainly just that nearly everyone who NEEDS a service account is probably combining it w/ some of the features this trigger gives you (just create your app, delete your trigger and re-add it w/ the V2 one).  

As well, I will follow this up w/ an article on the new parseJSON() function in the Experimental branch for Power Apps.  Because this kind of design also leans into a more genericized connection that JSON promises us.  The ability to pass A LOT of variables back/forth between a datasource and PowerApps using a single string is something that has a lot of promise.