Setting Up O365 Power Automate Workflows for SharePoint Notifications, Email Filing, and PDF Conversion

You have described three workflows that small teams ask for constantly, and they are all achievable on Microsoft 365 — but two of the three quietly depend on capability your current licensing probably does not include yet. Before building anything, it is worth separating what Power Automate can do with the connectors bundled into your plan from what needs a premium add-on. Getting that straight first saves you from building half a solution and hitting a wall on the part that matters most.

What Your Licences Actually Give You

You have 5 Microsoft 365 Business Standard licences and 5 Copilot licences. Business Standard includes "seeded" Power Automate rights, which let your users run flows that use standard connectors — SharePoint, Outlook, Exchange, OneDrive for Business, Teams, and approvals. That covers a great deal, including most of your notification and email-filing requirements.

What seeded rights do not include are premium connectors and certain actions: HTTP requests, third-party PDF engines, and anything that calls outside the Microsoft 365 standard set. Critically, your Copilot licences do not change this — Copilot for Microsoft 365 is an AI assistant, not a Power Automate entitlement, and it grants no premium flow rights. The PDF conversion and merging in your third workflow is the piece that will need either a Power Automate Premium licence (roughly USD $15 per user per month, and you typically only need it on the one account that owns the flow) or a specialist connector with its own subscription. So the honest summary is: workflows 1 and 2 run on what you have; workflow 3 will need one paid addition. Knowing that up front lets you scope the budget rather than discover it mid-build.

A Config-Driven Approach So You Can Maintain It

Before the individual flows, one design decision shapes all of them: do not hard-code folder paths, recipients, or subject references inside the flow. Every time those change you would have to edit the flow, which is exactly the dependency you want to avoid. Instead, create a small SharePoint list — a control table — that holds the configuration, and have each flow read from it.

For notifications, the list holds one row per monitored folder: the site, the folder path, and who to notify. To watch a sixth folder, you add a row — no flow editing. For email filing, a second list maps a subject-line reference (say a project code) to a destination folder. This pattern is the difference between an automation your team owns and one that only the person who built it can change. It directly answers your requirement to "add more yourself."

Workflow 1: Notify When a File Is Added or Changed in Specific Folders

This one runs entirely on standard connectors. The building block is the SharePoint trigger "When a file is created or modified (properties only)," pointed at the document library. Because that trigger fires for the whole library rather than a single subfolder, the flow then checks the file's folder path against your control list and only continues if it matches one of your monitored folders. From there it sends an email or a Teams message to the recipients named in that row.

Starting with your five specific folders, each becomes a row in the control list. When you want a sixth, you add a row with the path and the people to notify, and the same flow picks it up on its next run. A couple of practical notes: the "created or modified" trigger can fire more than once for a single upload as metadata settles, so it is worth adding a short condition to suppress duplicate notifications, and you will want to decide whether renames and metadata edits should count as a "change" or only new content. Microsoft documents the SharePoint triggers and their quirks in the Power Automate SharePoint connector reference, which is the right place to confirm exact behaviour.

Workflow 2: Save Emails and Attachments to SharePoint by Subject Reference

This is also achievable on standard connectors, using the Office 365 Outlook trigger "When a new email arrives." For each message, the flow reads the subject line, extracts your reference code, and looks that code up in the filing control list to find the destination folder. It then creates the file in SharePoint — the email body saved as a file, and a loop over the attachments saving each one alongside it.

The make-or-break detail here is how reliably you can pull the reference out of the subject. If your team already follows a naming protocol — a bracketed code, a consistent prefix, an invoice or project number in a fixed position — the extraction is straightforward and accurate. If subjects are freeform, you will get misfiled mail, so it is worth tightening the subject convention as part of this project. You should also decide what happens when no reference is found or the code is not in the list: the safest design routes those to an "Unsorted" review folder rather than silently dropping them. Run this on a shared mailbox if the goal is to capture team correspondence rather than one person's inbox.

Workflow 3: Convert Emails and Attachments to Separate and Combined PDFs

This is the powerful part of your request, and the part that needs a premium capability. There is no standard Power Automate action that turns an email — or an arbitrary attachment — into a PDF, and none that merges several PDFs into one. You have two realistic routes.

The lighter route uses OneDrive for Business's "Convert file" action, which can turn Office documents into PDF. Combined with saving the email body as HTML and converting it, this can produce PDFs without a third-party connector — but it is fiddly, does not handle every attachment type, and still cannot merge files. The robust route is a dedicated PDF connector such as Encodian or Plumsail, or the Adobe PDF Services connector. These provide exactly the actions you need: convert an email (and each attachment) to PDF, and merge multiple PDFs into one. They are premium connectors with their own subscription, but they turn this workflow from a brittle workaround into something dependable.

With a PDF connector in place, the flow does this: for each incoming email in a subject group, convert the message and every attachment into separate PDF files and save them into that subject's SharePoint folder. Then take all the PDFs now in that folder and merge them into a single combined PDF — for example "PROJECT-123 — Combined.pdf" — overwriting the previous combined file. Because the merge regenerates from whatever is in the folder, each fresh email that arrives (or is sent, if you also trigger on sent items) automatically grows the combined PDF on the next run. That "keeps adding to it" behaviour you asked for comes from rebuilding the combined file each time rather than trying to append to a locked document, which is the more reliable pattern.

Getting Your Tenant Ready First

You noted your licensing is "probably not configured adequately," and that instinct is right. A short readiness pass makes the build smoother: confirm the Power Platform environment your flows will live in, decide which account owns them (ideally a service or shared account, not an individual who might leave), enable the premium licence on just that owner account for workflow 3, and set data loss prevention policies so the new connectors are actually allowed in your tenant. It is also worth confirming the SharePoint sites and the shared mailbox permissions before you start, since most "the flow failed" tickets trace back to permissions rather than logic. If you are also weighing how Microsoft 365 fits your wider stack, our look at why some teams move between Microsoft 365 and Google Workspace covers the trade-offs.

Getting Help

Each of these flows is buildable, but the value is in getting the control lists, subject conventions, error handling, and PDF licensing right so the system runs unattended and your team can extend it without calling for help. If you would rather have it set up, tested against your real folders and mailboxes, and documented so you own it, our Workflow Automation service handles exactly this kind of Power Automate build — including advising on the most cost-effective licensing for the PDF conversion before you commit to a subscription. Get the foundation right once, and these three workflows quietly save hours every week.