Is there a difference between calling Microsoft Graph Endpoints using an HTTP action or creating a custom connector? In this post I will compare these two options.
Microsoft Graph in Power Automate
In the past I’ve used quite a few times Microsoft graph to do things in Office 365 from my flows in Power Automate. Today I tried to update a user’s password.
When i looked through the Microsoft Graph Documentation , I quite quickly found the options to update user details.
Quite quickly I found that I needed to have the following permissions
| Permission type | Permissions (from least to most privileged) |
|---|---|
| Delegated (work or school account) | User.ReadWrite, User.ReadWrite.All, User.ManageIdentities.All, Directory.ReadWrite.All, Directory.AccessAsUser.All |
| Delegated (personal Microsoft account) | User.ReadWrite |
| Application | User.ReadWrite.All, User.ManageIdentities.All, Directory.ReadWrite.All |
And this is where the problems start.
As always I created an App registration in Azure. And then i created the permissions as I needed them. Depending on how you call the end point you will need application permissions or delegate permissions.
Just applying both will not do the trick!
Delegated vs Application permissions
At this point it is probably a good idea to have a look at the difference between Delegate and Application permissions.
Microsoft Graph has two types of permissions:
- Delegated permissions are used by apps that have a signed-in user present. For these apps, either the user or an administrator consents to the permissions that the app requests and the app can act as the signed-in user when making calls to Microsoft Graph. Some delegated permissions can be consented by non-administrative users, but some higher-privileged permissions require administrator consent.
- Application permissions are used by apps that run without a signed-in user present; for example, apps that run as background services or daemons. Application permissions can only be consented by an administrator.
So the important thing the note here is that delegated permissions are being used when a user can consent to the use of the Graph API call.
When you apply the permissions within your app registration in Azure then you will notice that different things are possible depending on if you use the Delegated or if you use the Application permissions.
HTTP action
If I now create an HTTP action that tries to update the password of a user. I will receive an error
Insufficient privileges to complete the operation.
For quite a while I thought that this just meant that the user hadn’t consented to permission properly or that it wasn’t possible to use application permissions within a flow until i tried to do exactly the same with a custom connector.
I created an action called Update Password and I used my endpoint that I wanted to use. Okay, when you develop a proper custom connector you might want to clean things up a bit better. The example below is an example only, not a production ready custom connector.
Within the security tab of the custom connector editor, I’m specifying within the scope field which permissions i’m allowing my connector to use.
Then as a run my flow ( calling it from a Power App, my custom connector is actually updating the password for the user where as my http action is still failing).
So what does this mean?
To run my endpoint I seem to need application permissions. When i’m calling the end point from an http action delegated permissions are being used. When I now run the flow in the same way but I’m using a custom connector then the application permissions are applied.
So in short when the http action doesn’t work, it will be worth having a look into the options of a custom connector.