Hopefully my final edit... @PeteFromDenver alerted us that Microsoft has added a "Mailbox Address" field to Outlook actions. You can enter the address of the shared mailbox in this field to get back to original functionality. I'm keeping all previous solution details below just in case.
I've accepted the solution provided by @Anonymous on page 3. As a note for future users running into this issue, this solution requires a premium account. This will not be the best solution for a number of users (myself included), but it's the Microsoft-supported fix and (hopefully) the least likely to fail in the future.
For more information on the Graph API solution, check the posts by @jonathanford on pages 5 and 6.
If you do not have a premium account, the solution on page 3 offered by @Mindaugas is your best bet. You will need to add a new connection to Flow for the shared mailbox and then select that account as the connection for your Flow step. @RHCC gives more details on page 4 - you will also most likely need to add a password to the shared mailbox which is not intuitive.
This is by far the easiest solution, but I'm concerned how long it will work before Microsoft breaks functionality in an update. They do not support shared mailbox connections in Flows that don't specifically use that language, which is a frustrating response given how many users were relying on these Flows for their daily business.
Original post below:
Hi all - I'm having an issue with a couple Flows that were previously working without error.
When a new email arrives in a shared mailbox runs in a separate Flow and creates a SharePoint list item. One of the attributes added is the id of the trigger email (MessageId from the triggerBody).
I have two other Flows that will reply to this initial email using Reply to email. The stored MessageId is used to reply to the correct email. This has been working for 4+ months without error, but started failing today with the error shown in the Subject (Item Id doesn't belong to the current mailbox).
Myself and one other user are not having this failure. I had a user who was experiencing the failure check their connections in Flow and all apps were still connected. I also had them check their access to the shared inbox in Outlook and they still had full access.
Has anyone run into something similar or have any suggestions? It seems like it must be a user connection to the shared inbox but I'm not sure what else to look into. Thanks!
**Editing to note that the Get email step is also failing when referencing the ID of an email in a shared mailbox.
Solved! Go to Solution.
Yesterday the flow just seemed to break, giving the "Item Id doesn't belong to the current mailbox" error. I've deleted the connections, recreated a whole new flow, and still nothing. This is essential to our customer service team's productivity, so this is really killing us right now!
I opened a ticket with MS and after they did some research here is their response:
"using actions like “Get Email” and “Delete Email” in Shared Mailboxes is currently not supported, per the documentation for this connector: https://docs.microsoft.com/en-us/connectors/office365/#shared-mailbox-support. Only triggers and actions with Shared Mailbox in the name are supported.
This has been documented for some time but was working. It seems last week a change [with Outlook and Exchange] was finally made that broke this functionality. As mentioned in that documentation, the suggested workaround is to use the “HTTP with Azure AD” connector and the Graph API to work with items in Shared Mailboxes."
I've not had time to look into the linked document.
Then why in the world is their a trigger for Shared Mailbox? If it's not supported, don't give the option.
So we can trigger on a shared mailbox, but just email based on the trigger? Isn't that the only action with Shared Mailbox in the name? So we can't do anything with the email?
Even better... MS' own employees use the function.
Pretty much. The details about the email are available from that original trigger. But actions are no longer available via the Flow Actions. Instead, you will need to use the HTTP Service call and create the command to perform the actions that are still available. At least that is what the say in a generic response. The information in that link provides limited guidance.
At least the documentation says something like "the other operations do not support shared mailboxes as of yet." so they may be re-adding the actions via simple flow actions.
I think I could get over it, if I could just get a kick in my butt with how to get the HTTP with Azure AD action setup. I've done API work with JSON in Flow before. From some light research, I probably should've done it this way to begin with but man the other way was so much easier. If it wasn't supposed to work and it did and now they've broken it, it makes it all the more maddening.
I started having this problem myself and seem to have fixed it.
What I noticed was that the connection had changed on the delete email action from the shared mailbox connection to my own mailbox connection.
So, check that the connection you are using for both Get Email and Delete Email are the same, normally for the shared mailbox.
I found a "solution". Which is actually just doing what Microsoft is advising us to do: Use the Graph API.
First step is to use the HTTP with Azure AD connector: Invoke an HTTP request:
Then you have to create a new connection. In the documentation, Microsoft specifies that we must use "https://graph.microsoft.com/" as both the Base Resource URL and the Azure Resource URI:
Then simply click on "Sign In", and use your personal credentials.
Now you can simply refer to the Outlook REST API documentation (or the rest of Microsoft Graph).
Example on how to flag an e-mail:
Remember to change the shared mailbox in the URL: ENTERSHAREDMAILBOX@HERE.COM should of course be replaced with the shared mailbox that you are working with.
Hey Guys got this problem from Wednesday too. I have a flow witch reads mail in sharedmailbox, saves attachmetns to sharepoint and marks email as read.
1. First you have to know password of sharedmailbox IF Not go admin center -> active user -> find shared mailbox and get password.
2. Go to your MS flow that keeps failing. Then Edit.
3. Find action that is failing in my case it was "Mark as read or unread V2"
4. Then push 3 dots. And there is +Add new connection select it.
5. Enter sharedmailbox adress and password.
6. Checked if it appeared among other conections. As in step 4 if not try again. ( Few times needed for me.)
Wordked for me.
Okay, so that actually means that we need Premium to get this to work with Graph API? This is just great...
Is there any proper answer from MS, if all actions cannot be used with sharedmailbox or specific ones? Apparently Move Email still works for me, but other dont.
The same for me: I still have error at "Get Attachments" action in Flow.
I even can't create new connection with the shared mailbox address...
@Mindaugas, could you be more explicit on "how to add new connection with shared mailbox"?
The way I added the connection was through the left pane, Data > Connections > New Connection > Search Outlook > choose the Office 365 one > Create > enter credentials
From the Flow: click the three dots on your action and select the newly created Connection.
Thank you, @jonathanford!
But it doesn't worked for me, due to the fact I don't have permission to admin center settings.
I have solved the issue in other way:
1. I have created a rule for the specific shared mailbox to redirect all arrived emails to my personal mailbox;
2. I have created a second rule to move all emails arrived from the specific shared mailbox to my personal mailbox to move to a specific folder inside Inbox;
3. I have changed the trigger in Flow:
In this way, I ran from adding new user in Admin Center and creating new connections (connection with shared mailbox) in Flow.
Here's the generic setup to get all attachments once you trigger the email:
Where the Function for the URL is:
Learn how to create your own user groups today!
Check out the new Power Platform Community Connections gallery!
Join us, in-person, December 7–9 in Las Vegas, for the largest gathering of the Microsoft community in the world.