Tag / Power Automate

an anime character who has a slight beard and no hair, he is slim. He is happy because he has just solved the problem. The character is detailed and they are sat in a corner office. Behind the is a city scape scene.
by Simon Doy

Power Platform Error: Office 365 Connector – List Group Members Fails with Request_ResourceNotFound


This article details the findings of an investigation into a problem that we had with a Power Platform, Power Apps based solution. The reason for the issue is that this organisation needs to be more secure than most.

The organisation operates under numerous compliance and regulatory standards and the application that was built helped them implement one of their compliance based business process .
This solution happened to be one of the first solutions we rolled out. We hit an issue that we had not seen before. Looking around the Internet, it seemed that neither had many others. So, I want to document it and share what we saw so that others can get up and running faster than we did!
As they say, “Sharing Is caring!”

The issue was that a Power App was using the Office 365 Connector to List Group Members and it was failing with the following error:
Office365Groups.ListGroupMembers failed: { “error”: { “code”: “Request_ResourceNotFound”, “message”: “Resource ’33cd8c47-a8dc-XXXX-XXXX-a2a699b80f66′ does not exist or one of its queried reference-property objects are not present.”, “innerError”: { “date”: “2025-01-03T13:55:43”, “request-id”: “e0d458b3-0292-4624-96dc-10a4cccbe4ec”, “client-request-id”: “e0d458b3-0292-4624-96dc-10a4cccbe4ec” } } }

Checking the resource object id, which was for a user, they certainly did exist! Ultimately it was this that led us to the solution which I will detail below.

The code is shown below:

 
Investigation

We quickly realised that it was down to some sort of permission. One of the problems with troubleshooting is you do second guess yourself and we started to wonder if the problem was down to the users not being a member of a group. Well, one of the things that we need to mention is that the member of the group, was a Microsoft Entra ID Security Group. There are various settings which we checked but they never seemed to be the right problem.

The main issue we had is that we have a iThink 365 Development tenant with Power Platform Development environment and we could not recreate the problem.

Another thing to mention is that if a user was a SharePoint Administrator with a Microsoft Entra ID Role then the problem did not occur. We proved this by giving one of the users who we trusted that right and everything worked beautifully.

Anyway, after a couple of days of investigation between the teams I spent some time looking through all the Microsoft Entra ID policies and settings. I found the following Microsoft article: https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions.
One of the settings mentioned is “Read Other Users” which has the following description:

This setting is available in Microsoft Graph and PowerShell only. Setting this flag to $false prevents all nonadmins from reading user information from the directory. This flag might prevent reading user information in other Microsoft services like Microsoft Teams.
This setting is meant for special circumstances, so we don’t recommend setting the flag to $false.

The article did not explain how to make the change but after some searching an article was found which uses the Entra ID PowerShell module

The two commands that we used were:
Get Authorization Policy
This is used to get the authorization policy to see if the read other user permission was set to false.
https://learn.microsoft.com/en-us/powershell/module/microsoft.graph.entra/get-entraauthorizationpolicy?view=entra-powershell

Set Authorization Policy
This is used to set the authorization policy to set the read other user permission to true.
https://learn.microsoft.com/en-us/powershell/module/microsoft.graph.entra/set-entraauthorizationpolicy?view=entra-powershell

In turned out that the read other users permission was set to false!
Hurrah if we found something that could well be the problem, such a relief.. now to see if worked.

After a discussion with CTO and CIO who then mentioned some other issues that they were seeing ended up being related to this same setting. We got permission to make the change.


How long does the setting take to be applied?


One of the things that we were not sure of was, how long would the setting take to filter through the users.
Funnily enough it seemed to happen very quickly and when one of the users accessed the Power App it worked first time! So, to be safe give your users about 30 minutes for the change to take effect.

Conclusion


In this article I explained an issue we had with the Office 365 Group Connector which was reading the group membership and the users in the group. The Power App connector was failing.
This article explains how to fix the issue by setting the ReadOtherUser property to true. This is the default setting applied to accounts and it is unusual for the setting to be set to false.

I hope, not that if you are reading this and have this problem, this article will help you quickly resolve it! 😊

by Simon Doy

Resolving Power Automate Outlook Connector’s Create Event Operation Cannot find Calendar Issue


Photo by Jonny Gios on Unsplash

Introduction

One of my iThink 365 team called me up about creating events using the Outlook 365 connector and Create Event activity.

An image showing the Office 365 Outlook connector with the Create Event action.

The Create Event activity would successfully create an event when the Power Automate flow was run by the developer who created the flow. However, when the flow runs as anyone else then it failed with the following error,

“The specified object was not found in the store.”.

When we looked at the configuration of the Create Event operation we could see that the “Calendar”, calendar had been selected. So, if we have selected the right calendar, why is it failing? Why is it that Power Automate cannot find the Outlook calendar?

Well, the point is that the create event operation has a drop-down. This drop-down allows you to choose the name of the calendar to create the event in (as shown below).

However, when the calendar, “Calendar” is chosen it does not use the name of the calendar but rather the id instead. Each calendar has a unique id for each user’s mailbox. When we chose the calendar, rather than using a generic name, the Power Automate editor uses the calendars id. You can see that Id shown in the screenshot below (this was shown by clicking … for the operation and choosing Peek code).

So when Power Automate flow is running, it is running in the context of a user. In our example it is based on the user who started the flow. Now if the user is different to the developer, then they will have calendars with different IDs to the developer. So, in short, the error is right! The flow cannot find the calendar in the store because the calendar with the ID does not exist in the user’s mailbox!

Solution

So how do we resolve this and build something that works?

Well, we need to get the Id for the calendar and use that instead. How do we do that? Fortunately, there is an operation called Get Calendars which allows us to get all the calendars for the current user.

This operation will retrieve all the calendars in the user’s mailbox and using that it is possible to filter the array of calendars and select the id for the default calendar in the user’s mailbox.

This Filter array operation is then configured to take the output of the Get Calendars action and filter using the name “Calendar”.

Now, that we have the array item for the default calendar for the user, we can now use this with Create event by using the following formulae for the Calendar id.

first(body(‘Get_Users_Default_Calendar’))?[‘Id’]

Now that the Create Event action is using this formula to choose the Calendar Id, the operation will be able to find the calendar to successfully create the event in the user’s calendar. Regardless of which user runs the Power Automate flow!

Caveat

There is a caveat for this approach to work, firstly we need to ensure that the flow runs the connection in the context of the user who started the flow.

To do this, browse to the Power Automate Flow details page. Click edit next to the “Run only users” box. Change the drop-down to for the connector to say “Provided by run-only user”, as shown below.

Finally, set the Outlook 365 Connector to use “Provided by run-only user”.

The other point to make is that the flow will need to run in the context of the user that is having the event created in their calendar.

Therefore, there will be some design choices that you will need to make to ensure that the flow is started by the user who is to have the event created in their calendar.

This means that the flow cannot run off a system event or as an application as it will not have permission to write to the user’s calendar. Currently, the actions do not support being run as a service principal. If this were the case, it would be possible to give permission to write in every user’s calendar.

Anyway, hope that helps and please reach out if you have any questions on this.