How to Send Outlook Email Data to a SharePoint List

To send Outlook email data to a SharePoint list, build an automated cloud flow with the "when a new email arrives (V3)" trigger and the SharePoint "create item" action, then map the trigger outputs to your columns. That covers subject, sender, received time, and body. To fill the rest of your columns, parse the message into named fields first and map each parsed field to its column. SharePoint Online has no incoming email setting for lists, so a flow is the supported route. What the flow cannot do on its own is read meaning out of the message, and that is where most of these projects stall.

Can you email directly to a SharePoint list?

No. SharePoint Online does not support incoming email for lists or libraries. The feature existed in the on-premises SharePoint Server product, where a farm administrator configured an SMTP drop folder and a timer job to process it. SharePoint Online has no farm level configuration, so the setting was never carried across, and Microsoft has given no indication it is coming back.

What replaced it is the combination most Microsoft 365 tenants already have: a shared mailbox in Exchange Online and a Power Automate flow that watches it. Mail arrives at requests@ or facilities@, the flow fires, and a list item is created. It is more flexible than the old mail-enabled list ever was, because you decide what goes in each column instead of accepting a fixed mapping. You just have to supply the values.

How do I automatically add emails to a SharePoint list?

Create an automated cloud flow, choose the Outlook 365 trigger "when a new email arrives (V3)", and point it at the folder or shared mailbox you want. Add the SharePoint "create item" action, select the site and list, and map the trigger outputs to columns: Subject to Title, From to Requester, Received Time to a date column, Body to a multiple lines of text column. Save it and send a test message.

Filters on the trigger are worth setting up front. Restrict it to a folder, a subject keyword, or a specific sender, otherwise every newsletter and out-of-office reply becomes a list item. Turn off "include attachments" unless you plan to do something with them, since it makes each run heavier for no benefit.

At this point you have a working intake log. Whether it is useful depends on what you need to do with it. If the list only has to prove a message arrived, you are done. If anyone needs to filter by site, group by department, or total a quantity, keep reading, because none of those values are in columns yet.

How do I extract data from an email body in Power Automate?

The standard no-code method is an "HTML to text" action followed by string expressions that cut values out of the result. You use split() to break the body on a label such as "PO Number:", take the second element, then split again on a newline and wrap the whole thing in trim(). One expression per field. It uses only standard connectors, so there is no premium licensing involved, and for one machine-generated sender with a layout that never moves it is a perfectly reasonable answer.

The problem is what happens when the layout does move. Those expressions are pinned to exact wording and line order. A vendor reformats their confirmation email, adds a line, or changes "PO Number" to "Purchase Order", and the expression does not throw an error. It returns something, just the wrong something, and your list quietly fills with blanks or with fragments of the wrong line. Nobody notices until a report looks strange three weeks later.

The other route inside the Microsoft stack is AI Builder, which does real extraction but sits behind premium credits and is aimed mostly at structured documents. Between free-but-brittle and premium-but-document-shaped, a dedicated parser fills the middle: it reads the fields you name across varied layouts and hands them back as clean values. The mechanics of the native approach are covered in more depth in how to parse email body in Power Automate.

Why does the email body come into SharePoint as HTML?

Because the Outlook trigger returns the HTML version of the message by default, and the SharePoint text column stores whatever it is given. Adding an "HTML to text" action before the create item step converts it to plain text, which fixes the tags but usually leaves a run of blank lines from the original layout. Setting the multiple lines of text column to plain text rather than enhanced rich text also helps.

It is worth being honest about what you get even after cleanup: a readable but unstructured paragraph. A list where the useful values are locked inside a body column is one more place work goes to hide, which is the same reason large organizations end up bolting a search layer across every internal system on top of their file stores. Structuring the data at intake is cheaper than searching for it later.

How do I get an HTML table from an email into a SharePoint list?

Not with HTML to text. That action flattens a table into a run of words with the cell boundaries gone, so a five-line order becomes one unusable paragraph. Rebuilding rows from that string with flow expressions is possible in the sense that a very determined person can do it, but it is fragile enough that most teams give up and paste the table into a comment.

A parser handles it directly because it reads the HTML structure rather than a flattened copy of it. Each row in the table comes back as its own record, so an order with five line items produces five list items, each with its own part number, quantity, and price. That is the difference between a log you read and a list you can total in a view. The mechanics are covered in how to extract a table from an email, and the extract table from email workflow is built for exactly this.

What is the character limit for a SharePoint list column?

A single line of text column holds 255 characters. A multiple lines of text column holds 63,999. That sounds generous until a long reply chain arrives with a month of quoted history attached, at which point the item either truncates or the flow run fails. Storing eight named values instead of an entire conversation keeps every item comfortably inside the limit and makes the list smaller and faster to load.

How do I import a spreadsheet into an existing SharePoint list?

SharePoint will create a brand new list from an Excel file: choose New, then List, then From Excel, and the table headers become the columns. There is no equivalent import button for a list that already exists. To add rows to a list you already have, open it in grid view, click into the first empty row, and paste the block of cells straight from the spreadsheet. Match the column order first and the paste fills down cleanly.

This is the fastest way to clear a backlog. Parse the mailbox archive into a spreadsheet, line the headers up with your list columns, and paste. Years of past requests land in the list with their fields intact, which no flow can do for you because flows only see mail that arrives after they are switched on. Exporting the parsed messages as an Excel workbook or a CSV file gives you the file to paste from.

Can I save email attachments to SharePoint at the same time?

Yes, and this part Power Automate does well. Add a "get attachments" action and an "apply to each" loop with "create file" pointed at a document library, and every attached file lands in SharePoint with the item. Keep that step, because it solves the storage half of the job properly.

Be clear about the split, though. MailParse reads the email itself: headers, body text, and HTML tables. It records each attachment by filename, type, and size, but it does not open the file to read what is inside. If the numbers you need are in an attached PDF rather than in the message, that is a document extraction job, and it happens separately from parsing the mail.

Flow expressions or an email parser: which should you use?

Match the tool to the mail you actually receive. Here is an honest comparison.

Plenty of teams run both. The tidy machine-generated notifications go through a plain flow, and the messy human mail with tables and inconsistent formatting goes through a parser that hands the flow clean fields to map. Neither one has to win.

A setup that holds up

Start with a week of real messages rather than a sample you wrote yourself, because real senders are messier than any test. List the columns your SharePoint list already has and name one parser field for each. Run the week of mail through, look at the output next to the original messages, and fix the mapping until every value lands where it belongs, tables included.

Then pick your delivery. For a one-time load, export the CSV and paste it into grid view. For an ongoing feed, send the parsed fields as JSON to your flow and map each one onto the create item action, so the flow does what it is genuinely good at, creating items reliably, while the parsing happens before it. The full workflow is on the email to SharePoint list page, and if the same mailbox also feeds a spreadsheet or a ticket queue, extracting data from Outlook emails and email parser integrations cover where else those fields can go.