How to Parse Email Body in Power Automate (Step by Step)

Parsing an email body in Power Automate is one of those tasks that looks like a quick win and turns into an afternoon of trial and error. The data you want (an order number, an amount, a date, a customer name) is sitting right there in the message, but Power Automate doesn't hand it to you in neat fields. You have to strip the HTML, find each value by where it sits in the text, and slot it into an Excel table yourself.

This guide walks through the standard Microsoft 365 method end to end, with the exact action names and the expressions that do the work. Then it covers the three things that trip people up (HTML tables, attachments, and flows that break when a vendor changes their template) and shows a simpler path to the same result.

How do I parse an email body in Power Automate?

To parse an email body in Power Automate, build an automated cloud flow that starts with the "When a new email arrives (v3)" trigger, converts the message with the "HTML to text" action, pulls out each value with expressions like split, substring, and indexOf, and writes the results using "Add a row into a table" from the Excel connector. There is no single "parse" button; you assemble it from those actions.

The reason it takes several steps is that an email body is not structured data. It arrives as HTML, full of tags, inline styles, and formatting that mean nothing to a spreadsheet. Power Automate gives you the raw text and the string functions to carve it up, but you are the one deciding where each field begins and ends. That is the part worth getting right, so let's build it.

Step by step: extract data from an email body to Excel

Here is the recipe most tutorials land on, in the order you build it. The example assumes the emails follow a consistent layout (think order confirmations or form notifications from the same system).

1. Create the flow and trigger. From the Power Automate home page, choose Create, then "Automated cloud flow." Name it and select the trigger "When a new email arrives (v3)." Point it at the folder you want to watch and, ideally, filter by sender or subject so you only process the right messages.
2. Convert the body with "HTML to text." Add the "HTML to text" action and feed it the Body dynamic content from the trigger. This strips the HTML tags and gives you plain text, which is far easier to slice than raw markup. Without this step you would be parsing tags as well as content.
3. Find each value with expressions. This is the heart of it. For a label like Order number: 10482, you locate the label and read what follows. A common pattern is a Compose action with an expression such as trim(split(outputs('Html_to_text')?['body'], 'Order number:')[1]), or you use substring() together with indexOf() to grab the characters between two known markers. Repeat one Compose per field you need.
4. Optional: use Filter array for line-based data. If the body is a list of Label: value lines, split the text on new lines into an array, use the "Filter array" action to keep the line that starts with your label, then split that line on the colon and trim the spaces. This is steadier than counting character positions when the surrounding text moves around.
5. Write to Excel with "Add a row into a table." Add the "Add a row into a table" action from the Excel Online (Business) connector, point it at your workbook and a formatted table, and map each Compose output to a column. Power Automate generates an input box per column automatically, so you drop each extracted value into its matching field.

Run it once with a real email, check the row that lands in your sheet, and adjust the expressions until every field is clean. For a single, stable email format this works, and once it runs it runs hands-free.

How do I parse an HTML table from an email body in Power Automate?

To parse an HTML table from an email body in Power Automate, you generally avoid "HTML to text" (which flattens the table into a run-on line) and instead work with the HTML directly, splitting on the <tr> and <td> tags to rebuild rows and cells, or pass the body to a custom expression that rebuilds the grid. It is the most fragile part of the whole exercise.

The trouble is that "HTML to text" treats a table like prose. A tidy three-column table of line items comes out as one long string with the cell values jammed together, and you lose the column boundaries you actually needed. People work around it by parsing the markup tag by tag, which works until the sending system adds a column, nests a table, or changes its styling. If your source emails carry tabular data (invoices with line items, reports, order details), expect this step to need the most maintenance.

Can Power Automate parse email attachments?

Power Automate can detect and save email attachments, but reading the data inside a PDF, Excel, or image attachment is not part of the standard email actions. For that you need AI Builder (Microsoft's paid document-processing add-on with its own per-page licensing) or a third-party connector. The native email actions handle the body text, not the contents of files riding along with it.

This matters because a lot of business data lives in the attachment, not the message. A vendor emails "your invoice is attached" with a one-line body and a PDF that holds every number you care about. In that case the email-body parsing above gets you nothing useful, and you are into AI Builder credits or an external service to read the file. Worth knowing before you build, so you size the licensing correctly.

Why does my Power Automate email parsing keep breaking?

Power Automate email parsing breaks because the expressions are landmark-based: they find each value by its position relative to fixed text or character counts. The moment the sender changes their template (a new line, a renamed label, an extra row, different spacing) those landmarks move, and your split and substring expressions return the wrong text or fail outright. The flow does not error loudly; it often writes a wrong value and keeps going.

That silent failure is the real risk. Nobody notices until someone downstream asks why an amount looks off or a column is blank, and by then you have a week of bad rows to clean. The fragility is not a sign you built it wrong; it is inherent to parsing free-form text by position. The more senders and formats you handle, the more landmarks you are quietly depending on, and the more often one shifts.

Is there a simpler way to parse an email body to Excel?

Yes. A dedicated email parser does the same job without the flow, the expressions, or the per-format maintenance. You connect a mailbox or upload the email, name the fields you want once (for example order_number, amount, ship_date), and export clean rows to Excel, CSV, or JSON. It reads HTML tables as tables and lists each attachment by name, and it holds up when a sender changes the layout, the things the native flow struggles with most.

That is the gap MailParse fills for Microsoft 365 users. Instead of writing split() and substring() expressions and patching them every time a vendor tweaks a template, you describe the fields in plain language and let the parser find them, even when the layout shifts. If your end goal is simply structured data in a sheet, the email to Excel converter turns any inbox or message into columns without a single expression. Developers who want to push the output into another system can do the same thing through the email parser API with JSON and webhooks.

None of this means Power Automate is the wrong tool. If you already live in the Microsoft ecosystem, your emails follow one consistent, simple format, and the data you need is in the body rather than an attachment, the native flow is reasonable and keeps everything in one place. The calculus changes when you face multiple senders, frequent template changes, HTML tables, or attachment data: that is where the maintenance of an expression-based flow outweighs the convenience.

Power Automate vs a dedicated parser: which should you use?

Be honest about your inputs. One sender, one stable format, body-only data, and a team already standardized on Power Automate? Build the flow above and move on. Many senders, layouts that drift, tables, or attachments, plus a need for the numbers to be right every time? A purpose-built parser pays for itself the first time a vendor changes a template and your spreadsheet keeps working anyway.

The deciding question is not "can Power Automate do this," because it usually can. It is "how much of my month do I want to spend maintaining expressions when a layout changes." If the answer is "as little as possible," let a parser absorb the format churn. You can parse an email right now to see the rows appear, or read our breakdown of four ways to export emails to Excel for the wider picture.