Email body size exceeding SharePoint Enhance Multiline of text column

(0) Share

Report

Posted on by FW-07051511-0

156

I have a hit or miss error when photos are embedded in emails. The error is around the 63,999 character limit in SharePoint multiline of text field. Sometime, when an email has an embedded image the contentBytes section of the email leads to hundreds of thousands of characters.

I tried to use the length function to get the length of the email body but it only returned 12,271 characters but if I copy the email body output to a text editor it's showing hundreds of thousands of characters.

I tried to indexOf to find 'contentBytes' in the email body but it returned -1 like it didn't find it. I thought I could find contentBytes and truncate the email body there, but I cannot find it.

And I will mention again that this error doesn't happen every time for the same email it's hit or miss.

How do others deal with email bodies with too many characters?

Categories:

Building flows

I have the same question (0)

All responses (3)

Answers (0)

Sort by

Suggested answer

Sunil Kumar Pashikanti 2,267 Moderator on at

Like
a
(0)

Report
Copy link

Link copied!
Hi @FW-07051511-0,

This is a classic headache when working with email content, especially when inline images or complex email signatures are involved!

When an image is embedded directly into an email body (like a screenshot or a company logo), Outlook converts that image into a massive Base64 text string inside the HTML tags:

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA..." />

A single inline image can easily add 100,000+ characters of hidden text data

This makes the email payload size unpredictable, which is why your flow feels “hit or miss”

Why your checks failed:

contentBytes exists only in the attachments array, not in the body

length() may not reflect the full expanded payload during the write operation

Why SharePoint Fails
Even though SharePoint can store large text fields, when using Power Automate:

You’ll typically hit practical limits around ~64k characters per write
Inline image Base64 content easily pushes you past that

Best Ways to Fix It
1. Convert HTML to Plain Text (Recommended)
htmlToText(triggerBody()?['Body'])
Removes HTML and embedded images
Greatly reduces size

2. Truncate the Content Safely

if(

    length(triggerBody()?['Body']) > 50000,

    substring(triggerBody()?['Body'], 0, 50000),

    triggerBody()?['Body']

)

Prevents runtime errors on short emails
Keeps flow stable

3. Store Full Email as a File
If you need the full email (including images):

Save it as an .html file (SharePoint or OneDrive)

Store only a link in your list

Inline images create massive hidden Base64 strings in email HTML.
Best approach:

Clean it (htmlToText)
Truncate it
Or store it as a file instead

✅ If one of the responses here solved your issue, please mark it as Accepted so others facing the same problem can benefit as well.
👍 If this or any other reply here helped you, feel free to give it a Like. It helps others and is always appreciated.

Sunil Kumar Pashikanti, Moderator
Blog: https://sunilpashikanti.com/posts/

Was this reply helpful? Yes No
FW-07051511-0 156 on at

Like
a
(1)

Report
Copy link

Link copied!

@Sunil Kumar Pashikanti,

Whenever I tried the htmlToText it left a bunch of junk in the email body text when writing to SharePoint. Your option #2 won't work as you stated in the beginning the length of the trigger body will not include the attachment array length which has the contentBytes.

I will continue to experiment.

Was this reply helpful? Yes No
Sunil Kumar Pashikanti 2,267 Moderator on at

Like
a
(0)

Report
Copy link

Link copied!
Hi @FW-07051511-0,

That makes sense and yeah, htmlToText() can get pretty messy with all the spacing and structural tags depending on how complex the email formatting is!

Just to clarify one important architectural detail, because this is usually where the hidden trap lies:

You are absolutely right that standard attachments (PDFs, Excel files, etc.) live in a separate array and do not affect the body size at all.

However, inline images (like company logos in signatures or pasted screenshots) behave differently. Outlook converts those images into massive Base64 text strings and embeds them directly inside the email body HTML

(looking like <img src="data:image/png;base64,...">).

That is why a short, 2-line email with a single pasted screenshot can silently blow up to 150,000+ characters. Even though you don’t see the contentBytes property in the body text, that massive payload is still physically sitting inside the HTML string, which is what chokes the SharePoint write action.

Because it is part of the string, truncating the body length actually will protect your flow from crashing.

Two Practical Paths Forward
If htmlToText() is outputting too much junk, here are the two most reliable enterprise patterns for this scenario:

The Safe Truncate Check (Keeps HTML layout, caps length):
You can use an expression to check the length of the body. If it's too large, truncate it to 50,000 characters to keep it safe for SharePoint; if it's small, let it pass through normally:

if(greater(length(triggerBody()?['Body']), 50000), substring(triggerBody()?['Body'], 0, 50000), triggerBody()?['Body'])

Separate the Storage (Highly Recommended):
Use a Create file action to save the raw email body directly into a SharePoint Document Library or OneDrive folder as an .html file. Then, just patch a hyperlink to that file into your SharePoint list. This completely preserves the original email layout (images included) without bloating your list rows.

Good luck with the rest of your experimenting! Let me know if either of those options does the trick for you.

Was this reply helpful? Yes No