Nine Months of Outlook in n8n: The Good, The Bad, and The Graph API

If you’ve landed on this post, you’ve probably already hit one of the walls. You built what should have been a straightforward automation, Outlook did something completely unintuitive, and now you’re here trying to figure out if you’ve missed something obvious or if it actually is just that annoying.

Spoiler: it’s usually just that annoying.

We’ve spent the better part of nine months building n8n flows across a range of industries that all had Outlook sitting in the middle of them – medical practices, recruitment companies, property managers, you name it. What follows is an honest account of what works, what doesn’t, and where you’ll end up when the native nodes run out of runway.

First Things First: Credentials and Mailboxes

Before you write a single node, you need to understand one rule that will shape every Outlook automation you ever build: one credential, one mailbox. Full stop.

It doesn’t matter if the account you’re authenticating with has access to fifteen shared mailboxes. Each n8n credential is tied to a single mailbox – either the account you signed in with, or one shared mailbox that account can access. Pick one.

What this means in practice is that if you need to monitor multiple inboxes, you’re looking at multiple credentials, multiple trigger nodes, and a workflow structure that scales linearly with the number of mailboxes. It’s not elegant, but it’s the reality, and you’re better off knowing it upfront than discovering it halfway through a build.

Monitoring Subfolders: Where Things Get Fun

The Outlook trigger node in n8n fires on new message received. Seems obvious. Works great if emails land directly in the inbox you’re watching. The moment you introduce subfolders, things get interesting.

Here’s the gotcha: if an email arrives in the inbox and someone manually moves it into a subfolder, the trigger does not fire. As far as n8n is concerned, that email already existed – it just changed location. “New message received” means received by the server, not received by the folder.

The only scenario where the native trigger works reliably on a subfolder is if routing happens automatically at the server level, sending the email directly to that folder before any human touches it.

This is a real problem for any workflow that involves a human review step – say, an admin going through the inbox and dragging certain emails into a processing folder for automation. That’s an extremely common real-world pattern, and the native trigger won’t handle it.

The workaround is to ditch the trigger entirely for that use case and replace it with a scheduled poll – a time-based trigger that fires every few minutes, followed by an Outlook Get node that reads whatever is currently sitting in that subfolder. It works, but it comes with its own trade-off: your workflow runs whether or not there’s anything to process, which means your execution count climbs regardless of actual workload. If you’re trying to use execution history to understand how much work your automation is actually doing, that noise makes it harder to read.

Email IDs and Web Links: Nothing Stays the Same

This one catches people out repeatedly. Both the email ID and the web link for an Outlook email are tied to its current location. Move the email to another folder and both of them change. The old ones are invalid immediately.

For simple linear flows this isn’t a problem – you process the email and move it once at the end. But once your flows get more complex, particularly when you’re dealing with multiple attachments being processed in parallel or through sub-workflows, you’ll hit a situation where one process successfully moves the email and every other process that then tries to reference the original ID fails.

We’ve had flows that looked like one success and twenty-six failures that were actually working correctly – the email had been moved by the first completed process, and everything else was just trying to move something that had already gone. Not actually broken, but it’ll look broken if you don’t account for it, and anything downstream of that failed move step won’t run.

The practical takeaway: if you’re splitting work across multiple parallel paths that all touch the same email, you need error handling that accounts for “this email has already been moved” as an expected and acceptable outcome, not a failure state.

Attachments: Wider Than You Think

Downloading all attachments from an email sounds simple. And it is simple, right up until you realise that “all attachments” includes every image embedded in the email signature.

For flows that are only pulling PDFs, this is easy enough to handle – filter by file type and move on. But real business workflows often need to cast a wider net. When you’re building a pipeline that processes images, Word documents, Excel files, and PDFs depending on what a sender happens to attach, you can’t just filter by extension and call it done, because there’s a solid chance you’re also pulling in two or three signature logo files that look like attachments from n8n’s perspective.

We’ve had to build attachment filtering logic that combines multiple signals – file size, file name patterns, MIME type, and in some cases additional classification steps – to reliably distinguish between “this is the document we need to process” and “this is the company logo from the footer.” File name alone isn’t enough because people name files badly. File size alone isn’t enough because small legitimate documents exist. You usually need a combination, and the right combination depends on the specific workflow.

It’s solvable, but it’s one of those things that adds meaningful complexity to flows that should theoretically be straightforward.

Dynamic Attachments on Outbound Emails

Sending emails from n8n through Outlook is, genuinely, quite good. HTML in the message body, flexible From address options (provided your credentialed account has access to the address you’re sending from), read receipts, flags, importance levels – it all works cleanly and is well implemented in the native node.

The one place it falls down is dynamic attachments. Each attachment you want to include needs to be manually added as a row in the node configuration, targeting a specific binary object. If you know you’re always sending exactly one PDF, great. If you’re building a flow where the number of output files varies depending on what was processed, you’re stuck.

The workaround we’ve landed on consistently is to zip the output files into a single archive and send that. It’s not the most elegant user experience for the recipient, but it’s reliable and it handles any number of files without any changes to the node configuration.

The Email Body: Pick Your Poison

When you pull an email in n8n, you get a few different fields for the content:

• Subject – clean, reliable, does what it says
• bodyPreview – plain text, up to a character limit, good for quick checks but useless if you need the full content
• body.content – the full email body, but delivered as Outlook’s HTML

That last one is worth dwelling on. It’s not clean HTML. It’s Outlook’s particular flavour of fully structured markup, complete with all the inline styling and formatting cruft that Outlook loves to generate. If you need to do anything with the actual text content of the email, you’re going to want to strip that HTML down to plain text before you pass it anywhere.

If you’re sending it to an AI model, the model will work through the HTML and extract what it needs – but you’re burning extra tokens and adding latency to every execution just to have the model do something you could have handled in a pre-processing step. Clean the content first, then pass it downstream.

Headers: What n8n Doesn’t Tell You

Here’s one that doesn’t come up until it does, and then it’s a pain. n8n’s native Outlook nodes do not expose raw email headers. Even when you expand the full data output of an email node, the actual message headers aren’t there.

This matters more than it might seem. Email headers are where you’ll find things like forwarding chains, custom routing metadata, and anything that’s been stamped on the message at the server level. If you’re building any kind of advanced routing logic that relies on header values – and there are legitimate reasons to do this – the native nodes won’t get you there.

The solution is Microsoft Graph API calls via HTTP Request nodes, which brings us to the last section.

The Graph API: Your Frustrated Best Friend

Here’s the honest summary of working with Outlook in n8n: the native nodes are well built and cover the majority of common use cases competently. But Outlook is a deep platform and n8n’s nodes are a curated subset of what’s actually available.

When you hit the edge of what the native nodes can do, Microsoft Graph API is sitting right behind them, and it can do essentially anything. Custom headers, complex message operations, calendar management, delegated permissions, advanced search – if Outlook supports it, Graph can reach it.

The frustrating part isn’t that Graph exists. The frustrating part is the whiplash. You expect to be done in three clicks with one node, and instead you’re writing seven HTTP requests, managing auth tokens, parsing nested JSON responses, and building what is objectively a small API integration inside your automation workflow just to get one piece of information that you assumed would be there natively.

It’s not that Graph is bad. It’s extraordinarily capable and well documented. It’s that the gap between “this should be simple” and “okay we’re doing Graph calls now” can appear very suddenly and without warning.

The reassuring flip side is that there are virtually no hard walls with Outlook in n8n. Annoying walls, absolutely. Walls that require more effort than you budgeted for, definitely. But if something is possible in Outlook, it’s reachable from n8n with enough Graph API patience.

The Bottom Line

Outlook in n8n is genuinely useful and covers a lot of ground out of the box. But it rewards people who understand its quirks upfront, and it punishes assumptions.

If your flows are simple and linear, you’ll probably be fine with the native nodes and a bit of careful thinking around folder structure and email movement. If you’re building anything more complex – multiple inboxes, subfolder monitoring with human-in-the-loop steps, parallel attachment processing, custom routing logic – you’re going to run into most of what’s described above.

The good news is that all of it is solvable. The less good news is that “solvable” sometimes means a lot more work than the initial brief suggested.

If you’re mid-build and stuck on something mentioned here, or you’re scoping something and want to understand what you’re actually getting into before you start, feel free to reach out. We’ve hit most of these walls already so you don’t have to.

Get in touch if you’re looking for n8n consultants to help you automate Microsoft Outlook.