Is Power Automate covered by Microsoft's HIPAA BAA?

Clinics and practices that already run on Microsoft 365 often look at Power Automate first when they want to automate intake forms, referrals or appointment follow-ups. It is included in most Microsoft 365 business plans, and Microsoft signs a HIPAA Business Associate Agreement (BAA). So is it safe to send patient information through it?

The short answer: Microsoft lists the Power Automate cloud service as in scope for its BAA, whether bought on its own or included in an Office 365 or Dynamics 365 plan. But the BAA covers Microsoft's services only. The moment a flow passes protected health information (PHI) to a non-Microsoft app through a connector, that vendor needs its own BAA with you. Desktop flows, which run on your own Windows machines, raise separate questions. And having a BAA does not make your use of the tool compliant on its own. This article explains where the lines fall; it is not legal advice, so confirm your setup with your compliance lead or lawyer.

What Microsoft's BAA covers

Microsoft's HIPAA and HITECH compliance page, as of October 2026, lists "Power Automate cloud service either as a standalone service or as included in an Office 365 or Dynamics 365 branded plan or suite" among its in-scope services, alongside Power Apps, Power BI, Office 365 and Dynamics 365. The Office 365 table on the same page lists Exchange Online, SharePoint Online, OneDrive for Business, Microsoft Teams, Forms and Planner as in-scope commercial services.

Three points from that page matter in practice:

• You do not sign a separate document. Microsoft says its BAA is available through the Microsoft Online Services Data Protection Addendum by default to customers who are covered entities or business associates.
• Microsoft will not sign your BAA. It uses its own standard agreement for all customers.
• The BAA is not compliance. Microsoft states that using its services "doesn't on its own achieve HIPAA compliance". Your policies, access controls and the way you build each flow are still your responsibility.

Cloud flows that stay inside Microsoft

A cloud flow that moves data only between in-scope Microsoft services is the simplest case. Examples:

• A Microsoft Forms intake form that saves responses to a SharePoint list and notifies a Teams channel.
• An Outlook rule that files referral letters into a SharePoint folder per patient.
• A Planner task created when a new record appears in a SharePoint list.

Here every system that touches the data is listed under Microsoft's BAA. You still need to configure them properly: who can see the SharePoint list, whether the Teams message includes patient details or just a link, and who can edit the flow.

Connectors to non-Microsoft apps: where coverage stops

Power Automate's strength is its connector library, and that is exactly where clinics need care. A connector is a wrapper around another service's API, so when a flow sends data through a connector to a CRM, an SMS provider, an email marketing tool, an e-signature service or an AI model, that data is processed by the other vendor on its own systems and under its own terms. Microsoft's BAA does not extend to them.

The U.S. Department of Health and Human Services' guidance on cloud computing explains that a cloud provider which creates, receives, maintains or transmits electronic PHI for a covered entity is a business associate, even if it only holds encrypted data. In practice, that means each non-Microsoft service in a flow that carries PHI needs its own BAA, or the flow should not carry PHI.

Two details often catch people out:

• "Certified" does not mean "covered". Microsoft's data policy documentation describes certified connectors as ones Microsoft tests against its standards. Many are published by, and send data to, other companies. Certification is not a BAA.
• Many useful connectors are premium. According to Microsoft's licensing documentation, the Power Automate rights included with Microsoft 365 cover standard connectors only, so a flow to a non-Microsoft system often needs extra licensing as well as an extra BAA. Our comparison of Power Automate and Zapier for Microsoft 365 firms covers the license options.

The same logic applies to Zapier and Make, neither of which offers a BAA; see whether Zapier or Make are HIPAA compliant for the alternatives clinics use.

Desktop flows: a different question

Desktop flows (Power Automate for desktop) automate applications on a Windows machine by imitating clicks and keystrokes. Clinics sometimes use them to drive an older practice system that has no API. Microsoft's BAA list names the Power Automate cloud service; a desktop flow also involves your own machine, the application it operates and whatever the robot reads from the screen.

Some things to check with your compliance lead:

• Where the machine runs and who can sign in to it. The robot has the same access as the account it uses.
• What gets logged. Microsoft's documentation on desktop flow action logs explains that logs are stored in Dataverse and that capture can be set to always, only on failure, or off. Logs can contain the values a flow handled.
• Screenshots and files. Flows that save screenshots, exports or temporary files leave copies on disk that need the same protection as the record itself.

If desktop flows are part of your plan, ask Microsoft or your Microsoft partner to confirm in writing how they fit your agreement before you put PHI through them.

Controls worth setting up first

Power Platform includes governance tools that make a clinic's position much easier to defend:

1. Data policies. Admins can group connectors so that approved services cannot be combined with unapproved ones in the same flow, or block connectors entirely. Microsoft notes that policy changes usually take effect within an hour and can take up to 24 hours in large tenants.
2. A separate environment for any flow that handles patient data, with its own stricter data policy and a short list of makers.
3. Firm-owned connections. Run flows under a dedicated service account rather than an employee's login, so access survives staff changes and can be reviewed.
4. Minimal data in each step. Send a record ID or a link instead of clinical details wherever the next system does not need the details.
5. Hide sensitive run data. Power Automate's run history shows the inputs and outputs of each step; use the secure inputs and outputs settings on actions that handle PHI so they are not visible in the history.
6. A written inventory. List every flow that touches PHI, the services it calls, the BAA covering each one and the person who owns it.

A quick checklist before building a flow with patient data

• Is every service the flow touches listed under Microsoft's BAA, or covered by its own signed BAA?
• Does the flow need PHI at all, or would an ID or link do?
• Which license does each connector need?
• Is the flow in a restricted environment with a data policy applied?
• Who owns the connection account, and who is alerted if the flow fails?
• Has your compliance lead reviewed it?

How Flow Mesh helps

Our stack audit maps which of your tools and flows touch patient data and gives every tool a verdict (keep, configure, consolidate or replace), with a written scope for any changes. We work inside your own accounts, sign an NDA at the start and provide a DPA on request; your compliance decisions stay with your compliance lead. See how we approach healthcare clinics.

Key takeaways

• Microsoft lists the Power Automate cloud service as in scope for its HIPAA BAA, available through its Data Protection Addendum by default.
• Flows that stay within in-scope Microsoft services such as SharePoint, Forms, Teams and Outlook are the simplest case, but still need careful configuration.
• Any non-Microsoft service a flow sends PHI to needs its own BAA; a certified connector is not a BAA.
• Desktop flows involve your machines, the apps they drive and their logs, so confirm how they fit before using them with PHI.
• Use data policies, a separate environment, service accounts and secure run history before any patient data flows.