For a while, every emailed invoice, signed contract, or updated spec went through the same manual routine: open the email, save the attachment, work out which of six variously-named client folders it actually belonged in, drag it there, then delete or archive the email so it didn't turn up in next week's "have I filed this yet" search. Multiply that by every email that ever needed filing, and you've spent real hours being a very expensive filing cabinet.
None of that work required a human decision. It required a human to notice the email arrived, which is the one part computers are actually good at.
The trigger is the whole idea
The instinct when you first hear "automate this" is to imagine a script that runs periodically and checks your inbox. That's the wrong mental model, and it's the one that makes Power Automate feel more complicated than it is.
A cloud flow trigger isn't a check you schedule. It's a standing subscription you register once. You tell Outlook: whenever a message matching these conditions arrives, wake this flow up and hand it that message. From then on, nothing is polling your inbox and nothing is waiting for a timer to fire. The flow runs because the event happened, not because something went looking for it.
That's the actual advantage citizen developers have over waiting on IT: you get to notice the friction and build the fix the same afternoon, instead of filing a ticket and waiting for someone else's backlog to clear. Once the trigger exists, "did I file that" stops being a question you ask yourself, because it was never a task you were supposed to remember. It was an event you registered for.
What the trigger actually asks for
Every trigger in Power Automate has the same shape: a source, a filter, and how eagerly it checks. For email, that's the "When a new email arrives (V3)" trigger, and configuring it is really just answering four questions.
Folder: which mailbox folder to watch (defaults to Inbox)
To: optional - restrict to a specific recipient address
Subject Filter: optional - only fire when the subject contains this text
Has Attachment: optional - true/false, or leave blank for eitherThree variations of that same shape cover almost everything you'll want to build.
Subject-based: Subject Filter = "Invoice", Has Attachment = true - catches anything with "Invoice" in the subject line that also has a file attached.
Sender-based: leave Subject Filter blank, add a Condition action after the trigger checking From contains @supplier-domain.com - useful when subject lines are inconsistent but the sender isn't.
Folder-based: point Folder at a subfolder an Outlook rule already sorts into, and skip subject/sender filtering inside the flow entirely - let Outlook's own rules do the first pass, and let the flow handle only the filing.
Sorting invoices without touching them
Here's the version that actually replaces the manual routine: a solo consultant receiving supplier invoices by email, needing each one saved into a SharePoint library organised as Invoices/<Year>/<Supplier>.
The trigger is "When a new email arrives (V3)" with Subject Filter = "Invoice" and Has Attachment = true. After it, an Apply to each loops over the trigger's attachments, since a single email can have more than one. Inside the loop, a Condition checks the sender's domain against a short list of known suppliers, and each branch runs a Create file action in SharePoint, with the path built from dynamic content: Invoices/@{utcNow('yyyy')}/SupplierName/@{items('Apply_to_each')?['name']}.
Nobody opens Outlook to do this. Nobody remembers to do this. The invoice lands, and by the time anyone thinks to look, it's already sitting in the right folder with the year and supplier baked into the path. The only manual step left is deciding what counts as "the right folder", once, at build time, instead of every single time an email arrives.
Where the trigger stops helping you
It only sees email that arrives after the flow is turned on. Three years of backlog sitting in the inbox will not retroactively file itself; the trigger fires on new events, not existing ones. Clearing a backlog is a separate, one-time job.
It reads the envelope, not the contents. Subject line, sender, presence of an attachment - that's the entire vocabulary. If two suppliers send invoices with identical subject lines from personal Gmail addresses, the trigger can't tell them apart, because it never opens the PDF to check.
Shared mailboxes need their own scrutiny. The V3 trigger can point at a shared mailbox, but it authenticates through whichever account owns the flow, and losing access to that mailbox breaks the trigger quietly rather than throwing an obvious error. Worth testing the connection after any password reset or offboarding.
Renaming the watched folder breaks it quietly, too. The trigger stores a reference to the folder, not just its name at build time. Move or rename it and the flow keeps running against a folder that no longer resolves the way you expect, usually discovered only when files stop appearing where they should.
Frequently Asked Questions
Does this work with a shared mailbox, not just my own inbox?
Yes - point the trigger's Folder parameter at the shared mailbox instead of your own inbox, but the flow still runs under the connection of whoever created it. If that person loses access to the shared mailbox, the trigger fails silently rather than erroring loudly, so it's worth re-testing after any permissions change.
Can I filter on attachment file type instead of just the subject line?
Not inside the trigger itself. Add a Condition after the Apply to each that checks the attachment's name for the right extension, or use the attachment's content type if the source provides one.
What happens to emails that arrived before I built the flow?
Nothing. Triggers fire on new events from the point they're switched on. A backlog needs a one-time manual pass, or a separate flow built around "when a new file is created" if you move the backlog into a watched folder first.
Does this work if I want files in OneDrive instead of SharePoint?
Yes. The Create file action has both OneDrive for Business and SharePoint connectors, and the rest of the flow is identical - only the destination action changes.
What's the difference between the V3 trigger and the older V2 one?
V3 added separate filtering on To/Cc/Bcc, and more reliable attachment metadata. There's no reason to build on V2 today; it's kept around for flows built before V3 existed.
Will the flow break if two emails arrive at the same time?
No. Each trigger fire processes one email instance, and Power Automate queues near-simultaneous events rather than dropping or merging them, though very high volume can hit throttling limits worth watching if a mailbox gets hundreds of matching emails a day.
If turning one inbox habit into a standing trigger has you wondering what's next on the no-code ladder, Sunday's Deep End digs into that exact fork in the road: Learn Python, or learn to drive Copilot? A beginner's honest fork in the road.