What not to do: Power platform and the built-in connectors (Part 1)

Project Requirements

• You or the HR crew would like to have a nice, simple Power App to be able to create new users in Azure AD
• Requirements:
  • You can copy existing users as template users, edit the necessary details (UPN, Mail, etc.) to create new users with similar attributes (e.g., new Salesdude gets the same basic AAD attributes as current Saleslady)
  • Or you can start with a blank form and fill in the details yourself including all the relevant user attributes available in Azure AD such as companyName, city, state, employeeID, groupMembership, etc.
  • The app should be super user-friendly with the bare minimum required RBAC role rights in order to allow non-IT users (i.e., HR team members) to help on-board new colleagues
  • Let’s create and host it in Teams for familiar, easy access

Problem

• The fucking built-in, “free” Microsoft Connectors don’t do what we need ’em to!
• Only a few of the common Azure AD user attributes can be accessed, read, edited, or created by, you know, the damn AzureAD.CreateUser() command!
• The Office365Users.UpdateUserProfile() is equally as useless, as that connector offers no Create() command!
• The Office365Groups.ListGroups() command won’t even return what type of damn group it is!?!? Is it an MS365 Group? Dynamic or assigned? Security Groups? Distribution Groups? Forget it! Nothin’ doing! Oh but the AzureAD.AddToGroup() call only works for MS365 groups, and not distribution or mail-enabled security groups. But how can I tell the difference if I can “get” said difference!

Solution

• Bad news: You have to create your own custom connector to Microsoft Graph in order to read all or even most of the needed attributes when creating new users and groups. It is just is what it is.
• More bad news: custom connectors are “premium” features, so now you have to go to your boss, hat in hand and ask for a Power Apps per User license or Power Apps per App license

More Details

Coming from a background of writing automation scripts in PowerShell and PowerShell DSC, Power Platform (Power Apps, Power Automate, Power BI, Dataverse and co.) can be damn frustrating. Variables and type casting do not work the way you want them to, the developer UI is buggy and slow (looking at you CTRL+Z), and documentation from Microsoft is deeply lacking compared to PowerShell. Add all the crazy licensing as to what is premium and not premium and which flavor of license is the least exorbitant, plus the difference between the “free” Teams version of Power Apps (no Advanced Tools or Monitor here) vs the normal Power Platform environment, writing Power Apps for real-world business requirements will hurt your soul.

When they work, Power Apps look and feel great. Plus, there is tons of enthusiasm for automating basic business or IT tasks in a nice web-portal with little to no code writing skills necessary. Bosses love it and Microsoft IT guys will need to learn it.

Where the difficulties lie

I could write a novel about this experience but I will keep it short. Essentially the built-in or free connectors offered by Microsoft for the Power Platform are junk. They are demo products to entice you into the Power Platform environment, tempting you to believe that you can use Power Apps and Power Automate to create fully featured apps or automated flows, but they cannot.

Let’s take a simple example of trying to create a new user in Azure AD or MS365. Here are some of the different built-in connectors’ reference pages, explaining what their versions of the PowerShell command, New-AzureADUser, offer as input parameters:

Now, we have a lot of different ways to skin the same cat. But perhaps you have noticed something missing from the built-in connectors to the Power Platform? Let’s compare these attributes to what is available in Azure AD or with the New-AzureADUser PowerShell command we all know and love:

When you start to work with these commands for getting and creating new users in Power Apps, you will think you have taken crazy pills. I can’t set the CITY attribute of a new user with AzureAD.CreateUser()?!?! City?!?! companyName?!?! Department!?!? even though it is available in the AAD Users Dataverse table!?!?

Please do not make my mistake and create a Power App thinking that these connectors are worth your time. They will not work in production and are only good for cutesy little YouTube videos for overly enthusiastic developers hunting for clicks. It’s Mickey Mouse’s Power App and we are just living in it.

Start with the understanding that you will need to create a custom connector to Microsoft Graph before undertaking this project. So open up that wallet, get a real Power Apps license, and check out my next post, where I create said connector and integrate with Power Apps for real and not the stripped down Teams version.