Power Automate for Maintenance and Facilities Processes

Power Automate is the tool most maintenance and facilities teams already own and rarely use well. It sits inside the Microsoft 365 you are paying for, and with a few well built flows it can close the gaps your CMMS and BMS leave open: alarms that arrive as email and die there, PPMs that slip without anyone noticing, permits that expire on a Friday afternoon. This is a practitioner walkthrough of six flows worth building, what each one costs to run, and the discipline that keeps them alive after you move on.

I am writing this from the operations side, not the licensing sales side. Every flow below maps to a job I have actually needed done in a live estate. If you want the wider decision framework for when to automate at all, read my workflow automation buyers guide first; this piece assumes you have decided Power Automate is the right hammer and you want to swing it well.

Flow 1: BMS alarm email to CMMS work order

Most building management systems can email an alarm but cannot raise a work order. That gap is where reactive faults go to die in an inbox. This flow reads the alarm mail and creates the work order automatically.

• Trigger: "When a new email arrives" on a dedicated, service-owned mailbox that the BMS sends alarms to.
• Connectors: Office 365 Outlook (standard) to read the mail, then either the CMMS REST API via HTTP (premium) or Dataverse if your work orders live there.
• Failure mode: the BMS changes its subject-line format and your parsing silently returns empty, so work orders stop being created and nobody sees it. Parse defensively and alert on empty fields rather than writing a blank order.
• Licensing: the HTTP connector to your CMMS API is premium, which pushes this flow onto a per-flow or per-user premium plan. Standard Outlook alone will not get you there.

Flow 2: PPM overdue escalation to supervisor

Planned maintenance that slips is invisible until an auditor or a failure finds it. Your CMMS knows which PPMs are past due; it just will not chase anyone. This flow does the chasing.

• Trigger: "Recurrence" running once a day, early, before the shift starts.
• Connectors: HTTP or SQL Server (both premium) to query PPMs past their due date, then Office 365 Outlook and Microsoft Teams (standard) to notify.
• Failure mode: the query returns everything overdue every single day, so supervisors get the same fifty-line email daily and stop reading it. Escalate by age band, only notify on a change of state, and route repeat offenders up a level.
• Licensing: the data pull over SQL or HTTP is premium. The Teams and Outlook posting is standard, but one premium action in the flow sets the licence for the whole flow.

This flow pairs naturally with tightening the front door. If overdue work is a symptom of chaotic intake, my note on automating work order intake and triage covers the upstream half of the problem.

Flow 3: Permit expiry warning at T-minus-7

A permit to work that lapses mid-job is a safety event, not an admin slip. Seven days of warning gives the coordinator time to renew or stop the work in an orderly way.

• Trigger: "Recurrence" daily, scanning the permit register for anything expiring in exactly seven days.
• Connectors: SharePoint or Dataverse (standard, if your permit register lives there) or SQL/HTTP (premium, if it lives in the CMMS), plus Outlook and Teams (standard).
• Failure mode: a stored date in the wrong timezone or format shifts the seven-day window by a day, so warnings fire late. Normalise every date to a single timezone at the start of the flow and test across a month boundary.
• Licensing: if the register is a SharePoint list, this whole flow can run on standard connectors and the seeded Power Automate rights inside Microsoft 365. Keep it there if you can.

The document side of permits, storing them, versioning them, routing sign-off, is a bigger topic I cover in document and permit workflows.

Flow 4: Contractor insurance certificate expiry

Letting an uninsured contractor onto site transfers their risk onto you. This flow tracks certificate expiry dates and nags the contractor and your procurement lead before cover lapses.

• Trigger: "Recurrence" weekly, checking a contractor register for certificates expiring inside thirty days.
• Connectors: SharePoint list (standard) holding contractor records and certificate dates, Outlook (standard) for the external nudge, Teams (standard) for the internal one.
• Failure mode: the flow emails the contractor but nobody owns the follow-through, so cover lapses anyway. Copy an accountable internal owner on every external reminder and escalate if the date passes with no updated certificate uploaded.
• Licensing: fully achievable on standard connectors. This is the kind of flow that pays for itself in one avoided incident and costs nothing extra to run.

Flow 5: Work-order photo capture to SharePoint with asset metadata

Technicians take photos of completed work. Those photos usually sit trapped on phones or buried in a chat. This flow moves them to a structured SharePoint library and tags them with asset and work-order metadata so they are findable a year later.

• Trigger: a Power Apps or Power Automate mobile form submission, or a "When a file is created" watch on an intake folder.
• Connectors: Power Apps or the mobile trigger, SharePoint (standard) to store the image and write columns for asset ID, work-order number, and location.
• Failure mode: photos land with no metadata because the technician skipped the fields, leaving an unsearchable dump. Make asset ID and work-order number required at capture, and reject or quarantine anything missing them.
• Licensing: SharePoint is standard. If you drive capture through a canvas Power App, check whether your users are covered by seeded rights or need a Power Apps licence, which is a separate line from Power Automate.

Flow 6: Weekly SLA breach digest

Individual SLA alerts create noise. A single weekly digest of what breached, by client or category, gives managers something they will actually read and act on.

• Trigger: "Recurrence" weekly, Monday morning.
• Connectors: SQL Server or HTTP (premium) to query breached work orders against SLA targets, then Outlook (standard) to send an HTML table, or a Teams (standard) adaptive card.
• Failure mode: the digest goes out even when the query fails, sending an empty or zero-row table that reads as "all good" when in fact the data pull broke. Guard the send behind a row-count check and alert separately if the query returns nothing unexpectedly.
• Licensing: the reporting query over SQL or HTTP is premium, so this flow needs a premium licence even though it only sends one email a week.

Connectors and licensing, mapped

This is where facilities budgets get ambushed. Every flow above is free to build. The moment one action uses a premium connector, the whole flow needs a paid Power Automate plan, and you choose between per-user (a named person can run unlimited flows) and per-flow (one flow, any number of users, billed per flow per month). The table maps each flow so you can see the real bill before you commit.

*Standard for the flow itself; a canvas Power App front end may carry its own per-user Power Apps licence, which is billed separately from Power Automate. Confirm current tiers against the official Power Automate licensing types before you budget.

Error handling that stops silent failure

A flow that fails quietly is worse than no flow, because your team stops doing the manual step, trusting the automation, right up until they discover it broke six weeks ago. Three habits prevent that.

• Configure run-after. On critical actions, set the following action to run when the previous one fails or times out, not only when it succeeds. That is how you catch a failure and route it somewhere instead of letting the run just stop.
• Use scope try / catch. Wrap the working steps in a "Try" scope, add a "Catch" scope configured to run only when the Try scope has failed or timed out, and put your alerting in the Catch. This is the closest Power Automate gets to structured exception handling.
• Send every failure to one owned channel. Point every Catch block at a single Teams channel with a named owner. One place, one person accountable. Include the flow name, the run link, and the error so the owner can act without hunting.

Without that last habit, failures scatter across run histories nobody opens. With it, a broken flow is a message someone sees the same morning. Microsoft documents the run-after and scope patterns in the official Power Automate documentation .

Mistakes that sink FM flows

• Polling a mailbox someone else owns. Covered above and worth repeating: it is the single most common reason a flow that worked for a year suddenly stops.
• No deduplication on high-volume triggers. BMS alarms and sensor emails arrive in bursts. Without a dedup check you drown your CMMS in duplicate orders.
• Trusting parsed text. Subject lines and email bodies change. Validate what you extract and fail loudly on empty fields rather than writing junk records.
• Building in a personal environment. A flow that lives under one employee's default environment vanishes with their account. Environments matter, which is the next section.

Naming, environments, and ownership

The difference between a flow that survives its author leaving and one that dies with them is convention, decided before you build, not after.

• Naming. Adopt a fixed pattern such as FM-[Trigger]-[Action]-[Frequency], for example FM-PermitExpiry-NotifyCoordinator-Daily. A person who has never seen the flow should understand what it does from the name alone.
• Environments. Build in a shared, department-owned environment, never a personal default one. Keep a separate dev and production environment so you can test changes without breaking live processes, and use solutions to move flows between them cleanly.
• Ownership. Give every flow at least two owners, ideally a shared service account plus a named team, so no flow is a single person's private property. Store the connection references and any API secrets in a documented, shared place.
• A register. Keep one list of every production flow: name, purpose, trigger source, connectors, licence, and owner. When someone leaves, that register is the difference between a handover and an archaeology project.

Conclusion

Power Automate does not replace your CMMS or your BMS. It stitches the gaps between them and pushes the right message to the right person at the right time. Start with the two or three flows that map to your worst current pain, usually PPM slippage and permit or insurance expiry, build them on standard connectors where you can, and only reach for premium when the value clearly justifies the licence. Then wrap every one in real error handling, a shared owner, and a naming convention, so the automation outlives the person who built it. That last part is what separates a resilient operation from a pile of orphaned flows.