Power Automate vs Make for Microsoft 365 teams

Short answer: choose Power Automate if your data is in SharePoint, Teams and Outlook, because Microsoft 365 plans include standard connectors. Choose Make if you connect many non-Microsoft apps and want a visual canvas; Make bills by credits, and Power Automate bills by license. Both can do both jobs, so the choice depends on where your data lives and who will fix a flow when it breaks.

Disclosure: I build on Microsoft 365. I build Power Automate flows for a living, so I have a side. Below I say where Make wins. Prices and limits change, so check each vendor before you buy.

What each tool is

Power Automate is Microsoft's automation tool. You build a flow: a trigger starts it, and actions run after it. An example is "when a row is added to a SharePoint list, ask a manager to approve."

Make is a separate company's automation tool. You build a scenario: modules sit on a canvas and connect to each other. Make is not tied to Microsoft. It connects many apps, and you can run branches with a Router module.

Also looking at Zapier? See "Power Automate vs Zapier for Microsoft 365 teams".

How you build

In Power Automate, you add a trigger, then add steps one after another. Microsoft Learn describes a designer with a left menu item called My flows and a Create from blank option. Steps for Outlook, Teams and SharePoint are in the same list as every other step.

In Make, you place modules on a canvas and link them. The help center lists a Router and several error handler modules that you attach to a module.

Neither build style is better for everyone. A person who thinks in pictures may like Make. A person who already lives in Outlook and Teams may like Power Automate.

Error handling and visibility

This is where the two tools feel most different, so it is worth reading slowly.

Power Automate, as Microsoft Learn describes it:

Run after settings let you say what happens if an action fails, times out, is skipped or succeeds. For example, send an email when the Update a row step fails.
You can group steps into scopes and use a "Try" scope and a "Catch" scope.
A retry policy can retry an action at fixed or exponential intervals.
A Terminate action stops a flow and sets a status such as Failed.
The flow service sends email alerts to flow owners for failures such as broken connections or throttling.
Run history: select a flow in My flows, then Details. The page names a 28 day run history section, and you can open a run to see the inputs and outputs of each step.

Make, as the Make help center describes it:

Error handler modules: the help page lists Skip, Retry, Resume, Commit and Rollback. Skip disregards the error and lets the scenario go on. Retry stores incomplete executions and allows automatic or manual retries. Resume sets a substitute value for the failed module and continues. Commit stops the scenario and saves the changes made so far. Rollback stops the scenario and reverts changes.
History tab: each scenario has a History tab with run entries. An entry shows date and time, status (Success, Warning or Error), duration, operations, credits and data transferred, plus a replay option. Click Details to inspect the output of a single module. You can export history to CSV.
Scenario settings let you set how many errors in a row are allowed before Make switches a scenario off. For scenarios that start with an instant trigger, it switches off after the first error.
The help page says how long history is kept depends on your plan. I did not find a number on the page, so I do not give one.

Where Make wins here: error handling is a visible part of the picture. You can see a handler attached to a module, and the choice of Rollback or Commit is built in. The per-module output view in History is easy to read for someone who is not a developer.

Where Power Automate wins here: Run after and scopes use the same logic you may already know from other Microsoft tools, and the failure emails go to the flow owner without extra setup.

Price and how it is counted

The two tools count different things.

Make counts credits. Make's credits help page says credits replaced operations as the billing unit, and that by default 1 operation equals 1 credit. Some AI modules use more. Make's pricing page says the Router module and the error handler modules use no credits. Read Make's current plans and prices on its pricing page: https://www.make.com/en/pricing

Power Automate is counted by license, not by step. Microsoft's licensing FAQ says users with the free plan or a Microsoft 365 plan can only use standard connectors, and that if a flow does not use a premium connector, you do not need a Premium license. Check Microsoft's current pricing page for Premium and Process prices: https://www.microsoft.com/en-us/power-platform/products/power-automate/pricing

What this means in plain words: with Make, more steps and more runs use more credits, so volume drives the bill. With Power Automate, the bill depends on connector type and who owns the flow, so volume matters less for standard connectors, but a license check matters more. Check with your admin what your Microsoft 365 plan includes.

Limits that matter

Power Automate, from Microsoft Learn:

A single run can last up to 30 days, which includes flows that wait on an approval. After 30 days, pending steps time out.
The shortest repeat interval for a scheduled flow is 60 seconds.
A flow that fails continuously for 14 days is turned off.
A flow that is not triggered for 90 days might be turned off. Flows owned by users with premium licenses, or flows with a Process license, are not subject to this.
You can have up to 600 flows in your account.

Make: Make's run time limit and minimum interval depend on the plan, so I state none here. Look at the Make pricing page for the limits of the plan you are considering.

Microsoft 365 apps

Power Automate has Microsoft 365 apps in the same product: Office 365 Outlook, SharePoint, Teams and others. Standard connectors are covered by a Microsoft 365 plan.

Make also lists apps for Microsoft services. The exact modules for SharePoint or Teams can differ, so check what each one does. Before you pick Make, open its app list and check that the trigger you need exists. Also check whether sign-in to your company tenant needs an admin to approve it.

Side by side

Plain text rows. Each row shows the need, Power Automate, then Make.

Build style: Step list in a designer | Modules on a canvas

Unit that drives cost: License (user or bot) | Credits (1 operation = 1 credit by default)

Included with Microsoft 365: Standard connectors | Not tied to Microsoft 365

Error handling: Run after, scopes, retry policy, Terminate | Skip, Retry, Resume, Commit, Rollback modules

Run history: 28 day run history in My flows | History tab per scenario, retention depends on plan

Approvals: Built in, waits up to 30 days | Check Make's app list for an approval step

Microsoft 365 fit: Native | Through apps in Make

Outside apps: Some need premium connectors | Built for this

Pick Power Automate if

Your data is mainly in SharePoint, Teams, Outlook or Excel.
You need approvals that wait days for a person.
You want to avoid a new vendor and a new login.
Your IT team wants one place to see and control automations.

Pick Make if

You connect many apps outside Microsoft and want to see the data path on one canvas.
You want error choices such as Rollback or Commit as visible modules.
You are comfortable owning a separate tool and its bill.

What to avoid

Do not choose on price alone. Count what your flows use first.
Do not run two tools with no list of who owns what. A broken flow is hard to find.
Do not skip error handling. A flow with no failure step fails quietly.
Do not trust a price in any guide. Open the vendor page on the day you buy.
Do not build a large flow before you build one small one and watch it run for a week.

When to use both

Our advice, not a Microsoft rule: keep the flows that touch SharePoint, Teams and Outlook in Power Automate, and put the flows that only link outside apps in Make. Write down which tool owns each flow, so a broken one is easy to find.

How to choose

List the apps your flow touches. Mark which are Microsoft.
Check in Power Automate whether any step needs a premium connector.
Estimate how many steps your flow runs in a month. Check the credit rule on Make's pages.
Ask who will fix the flow when it breaks. Pick the tool that person already knows.
Build one real flow in each tool and compare the run history.

When to get help

You can build all of this yourself in Microsoft 365. If you would rather have it built and tested for your team, I do that. A tracker with flows like these is a fixed price: $5,000 for one, built in 2 weeks. See "What a SharePoint tracker costs to build". Bring one example of the problem to a free call.

Tell me what's still manual

I am Al Davies. I run 250 High Street LLC and build SharePoint trackers and Power Automate flows for operations teams. I work remotely. The first call is free, and I will not try to sell you anything.

See trackers I built: Tools I built

FAQ

Is Power Automate free with Microsoft 365?

Microsoft's licensing FAQ says users with a Microsoft 365 plan can only use standard connectors, and a flow without a premium connector does not need a Premium license. Check Microsoft's current pricing page for prices.

How does Make count usage?

Make counts credits. Its credits page says 1 operation equals 1 credit by default, and some AI modules use more.

How do Power Automate and Make compare with Zapier?

See "Power Automate vs Zapier for Microsoft 365 teams" for the Zapier comparison.

Which tool shows errors better?

Both show runs and let you open a run to see step details. Make shows error handlers as modules on the canvas. Power Automate uses Run after settings, scopes and email alerts to the flow owner. Which one feels clearer depends on the person reading it.

How long is run history kept?

Power Automate shows a 28 day run history section on the flow details page. Make says history retention depends on your plan, so check the plan you want.

Can I switch from Make to Power Automate later?

Our advice, not a Microsoft rule: plan to rebuild each automation by hand. List each scenario, its trigger, its steps and its owner, then rebuild one at a time.