Add the capability for tenant service accounts
As we build solutions in Office 365, we often need the concept of service accounts, but there's no mechanism for this - other than setting up a fake user account. It's quite common to need an identity that isn't tied to a specific person, not unlike what we typically do on premises.
The idea would be that these service accounts could have the restriction that they wouldn't have a login, so they would have no mailbox, no OneDrive etc., but could be secured like any other AD principal.
Here are some example uses for this type of account:
* As the identity under which a Flow or PowerApps would run. This would mean that the service account could have the least required permissions to create the necessary connectors within Office 365, but the identity would make more sense for actions like sending emails.
* In PowerApps, using a service account to do something or reach into content sources in a certain way that cannot depend on the current user's credentials. For example, reaching into HR's site for a particular list of information curated specifically for the request or user which would be displayed on a form.
Additionally, these service accounts should not incur licensing charges, since they wouldn't be used by any actual person. Currently, we end up creating fake users (maybe Firstname: HR, Lastname: Administrator) and paying the monthly licensing charge for them.
Finally, having these service accounts would greatly improve the solutions outside consultants can provide in Office 365. It rarely makes sense to see an email coming from a consultant or a list item created by a consultant who used to work in the tenant or to have that consultant's identity tied to any solution. In Flow, we can make individual Flows into Team Flows, but the consultant identity is still stuck in the owners list. Some sort of service account would decouple the person creating the solution and the identity running it.
Mark Weinhardt commented
Or, as I like to call it, "The way it worked in exchange before".
Create a shared mailbox. Create a service account. Grant service account access to shared mailbox. Apps use service account credentials to access shared mailbox. No license incurred.
Anthony Kasses commented
We have many peripheral applications that feed into SharePoint to achieve basic operations that don't require access beyond 'guest' privileges. These systems needs to use a service account this is not tied to a person. Please Microsoft consider this request seriously.
Marc D Anderson commented
Having a specific way to do this rather than a rather obtuse workaround (you need to understand the platform pretty deeply to even understand that you're probably painting yourself into a corner with "regular" user accounts) would make very good sense. So the ask for Microsoft is to devise a more formal "service account" capability which is supportable as such and more obvious to use.
Does this boil down to not wanting to assign licenses for accounts that are used for larger work processes (like a Flow that is used by all users and accesses sensitive data using elevated privileges as you mention)?
As you point out, you can certainly setup accounts that meet the criteria of having elevated privileges in whatever environment you need (HR system in your example) and then hooking that up to a PowerApp or Flow.
If you don't want that account to have a mailbox or OneDrive or any other Office 365 workload, you can disable those assigned plans depending on their license.
But you would presumably still need the account to have the appropriate Office 365 license and plans enabled to run the PowerApp or Flow and access the Office 365 services it is dependent on.
This question has come up quite a bit in a our PowerApp and Flow workshops. That is, organizations don't want to have a broadly used, extremely important Flow running under the context of a single user account when that user may or get hit by a bus or win the lottery, or get mad or whatever. So, yes, a "service" account that is setup and managed appropriately makes sense. But I am unclear of what the ask is for Microsoft. We do this all the time today already...other than not assigning a license.