Showing results for 
Search instead for 
Did you mean: 

Overcome 4MB mail limit sent from Microsoft Flow

On 21st August 2019 Microsoft announced that actions in Microsoft Flow from Outlook stack, are going to be moved from using Outlook REST API v1.0 to Microsoft Graph v1.0. Along with that information there was also written, that current Outlook API 1.0 is going to be decommissioned in 1st of November 2019. So after that date all old actions in Microsoft Flow are going to be removed too.

There would be nothing wrong with this transition, moreover – it is motivated by important arguments, however together with positive aspects it has one, significant negative issue: total size of the message sent to Microsoft Graph v1.0 API and the size of each attachment cannot exceed 4MB. That means – large attachments simply cannot be sent from Flow anymore.


The story behind

When browsing the internet looking for any sort of workaround or information about when the problem is going to be solved, I found these two assets:

  1. UserVoice entry: – confirming this issue is a struggle for many users…
  2. Github discussion:

The Github one made me somehow more happy, as I read there, that Microsoft is like weeks away from releasing the beta update, allowing to send messages with attachments bigger, but without a precise information how big. But “weeks” can mean 2 or 10. And the requirement from one of my customers was very clear and urgent – we need to be able to send attachments bigger than 4MB using Flow.


The workaround aka solution

The solution to overcome 4MB attachments sent from Microsoft Flow that was mentioned mostly often (user Alhric Lacle shared parts of CSOM code) was the one encouraging to use Outlook REST API v2.0 that is not going to be decommissioned (or at least at the time of writing this post there was no information about that).



At first idea was quite simple to me:

  1. Create Azure AD app
  2. Grant it application permissions for Mail.ReadWrite and Mail.Send scopes
  3. Grant administrator consent
  4. Use one HTTP request action to call authentication endpoint to get Bearer token
  5. Use the token to send e-mail with attachments using defined in documentation methods:

During test with Postman I realized, that this is impossible however. Even though I was able to obtain bearer token, I wasn’t able to call endpont to send mail, as I was constantly receiving access denied.

The reason why I think it was happening was due to the fact, the app was registered in a context of the application, not a user, but the API was expecting context of a user. But that’s just a guess.

Nevertheless, after failing several times more I asked Twitter for help:


Looking for help. Need to call Outlook REST API v2 from #MicrosoftFlow. I can get Bearer token, but calls to get messages are access denied. Why? 😃

— Tomasz Poszytek #PowerAddict @ #aOSSG 🇸🇬 (@TomaszPoszytek) October 10, 2019

And the help came from Vivek Bavishi (thank you pal!). He suggested to use built-in action in Microsoft Flow, called “Invoke an HTTP request” from the “HTTP with Azure AD“.



Important! These action are premium. You need to have Flow per flow license or per user to use them.


I decided to give it a try. The biggest difference between using the built-in actions and the HTTP requests is that in the OOTB approach there is really no need to first call authentication endpoint to obtain bearer token.


Important! All names in JSON schema are camelCased. Therefore be sure to really copy them 1-1 from the documentation examples.


I decided to use endpoint called{USER-EMAIL}/sendmail to send a message on behalf of a shared mailbox.


Important! When creating a connection be sure you are using credentials of a user who has permissions to send on behalf of other user/ mailbox. That’s the key point in this approach.


I also wanted my message to be sent to multiple recipients. There are two arrays: 


"ToRecipients": [   ],
"CcRecipients": [   ],

In each you need to put every recipient’s e-mail in a separate block:

  "EmailAddress": {

Therefore you cannot simply put a string with multiple, semicolon separated e-mails.

I prepared those blocks, by first splitting and then immidiately joining a list of semicolon separated e-mail adressess, by using the below expression:

split(body(';', ';')

For this purpose I used action called “Join”. The “Join with” string was:

"}},{"EmailAddress": { "Address": "


So that they perfectly fit then inside the block:

  "EmailAddress": {

Next step is to attach documents. Here the crucial think to remember is that the contents of the file must be base64 encoded. Files are stored in an array named “Attachments”:

"Attachments": [   ]

Each attachment is an object, built using the following schema:

  "@odata.type": "#Microsoft.OutlookServices.FileAttachment", 
  "Name": "FILENAME", 

There are also additional options in the schema, such as “SaveToSentItems”, however the main core of the action are recipients, contents of the mail and attachments. The final action just to send the mail on the fly looks like:


The biggest file I tried to send was 18MB, however it should be possible to send files up to 50MB as well.

I hope you find this post helpful. And that it will save you a lot of time searching how to overcome limit. I also personally hope that it information written here will very soon get useles because of the increase in limit present in Graph API v1.0 😉


Stay tuned!


OMG - you rock!!


I have been fighting with the non-preview SendFromSharedMailbox(V2) file size limit for weeks!!


Of course just yesterday I get an email that the underlying issue with GraphAPI 4MB limit for attachments has a fix.


Still until the Office 365 Outlook connector supports the new call, I can leverage your solution.


Thank you!!!

I'm glad it helped you 🙂

Meet Our Blog Authors
  • Working daily with Microsoft Cloud to deliver the needs of my company, my customers and various Microsoft communities and forums. | Office 365 | Flow | PowerShell | PowerApps | SharePoint |
  • Co-founder of, Office 365 and SharePoint expert. Passionate about design and development of easy to use, convenient and flexible products.
  • Microsoft Business Apps MVP. Owner of ThriveFast, an Office 365 consulting company.
  • 7x Microsoft Business Solutions MVP (CRM)
  • I'm keen in MS technologies, SharePoint, Office 365 and development for them
  • Daniel is a Business Productivity Consultant & Microsoft Business Solutions MVP who is very enthusiastic about all things Office 365, Microsoft Flow, PowerApps, Azure & SharePoint (Online). Since the preview, Daniel has been working with Microsoft Flow and later on with Microsoft PowerApps. That led to him being awarded an MVP Award for Business Solutions. He loves to blog, present and evangelize about improving productivity in the modern workspace with these amazing tools!
  • Michelle is an Office 365 solution architect in Twin Cities, MN. She has been delivering business collaboration solutions for years with her focus on SharePoint and Office 365. Michelle is a recent board member of the Minnesota Office 365 User Group and has been a member of the SharePoint community since 2009. She is a frequent speaker at MNSPUG and SharePoint Saturday and co-chaired the Legal SharePoint User Group for 4 years. Her most frequent projects have involved rolling out a large deployment of Office 365, SharePoint Online intranet, build of a "CHAMPS" Office 365 user adoption program and most recently, SharePoint On-Premise to Online Migration. Michelle is very excited about cloud technology as it is shifting her IT Pro focus to collaboration strategy and technical adoption.
  • I'm a Microsoft Office Servers and Services MVP with a special interest in SharePoint, Office 365, Microsoft Flow, Microsoft Teams and PowerApps. I work at Triad Group Plc (
  • Passionate #Programmer #SharePoint #SPFx #Office365 #MSFlow | C-sharpCorner MVP | SharePoint StackOverflow, Github, PnP contributor