Make vs Power Automate in 2026: the Microsoft 365 decision guide

You can build the same-looking automation in Make and Power Automate, then discover six months later that you chose the wrong operating model.

The diagram was the easy part.

The real differences appear in connections, identity, connector depth, data policy, error recovery, usage costs and who can support the workflow after its creator leaves.

There is no universal winner.

For Microsoft 365 users, Power Automate is usually the natural starting point for Microsoft-first internal processes. Make becomes especially interesting when the process crosses several non-Microsoft SaaS products and benefits from its visual bundle-and-mapping model.

But “usually” is not a buying decision. This guide gives you a repeatable test.

Affiliate disclosure: Collab365 is a Make affiliate. If you register through a marked Make link in this article, we may receive a commission. It does not change your price. The comparison criteria below apply equally to both products.

The short answer

Start with Power Automate when most of these are true:

• the process begins and ends in Microsoft 365 or Dynamics 365;
• SharePoint, Teams, Outlook, Dataverse or approvals are central;
• Power Platform environments and data policies already govern automation;
• Microsoft Entra identities and tenant administrators own the process;
• an on-premises data gateway or Power Platform custom connector is part of the design;
• the solution must travel through an established Power Platform application lifecycle.

Put Make on the shortlist when most of these are true:

• the workflow crosses several external SaaS products;
• Make’s exact modules cover the triggers and actions you need;
• visual inspection of bundles, mappings and routes will help the support team;
• the organisation has an agreed Make team, role and connection model;
• the credit cost has been tested with representative data volume;
• the required security, residency, audit and support features exist in the plan being considered.

Choose neither until you have tested the actual workload.

What the platforms call the same ideas

Workflow idea	Power Automate	Make
Automation	Cloud flow	Scenario
App/API operation	Trigger or action in a connector	Trigger, action or search module
Data moving through a run	Dynamic content/action outputs	Bundles and mapped data items
Branching	Condition, Switch, parallel branch, Scope	Router, filters and routes
Failure inspection	Run history and action outputs	Scenario history, operations and bundles
Reusable API wrapper	Custom connector	App/custom app or HTTP module
Organisational boundary	Tenant, environment, solution and connections	Organisation, team, scenario and connections

Similar words do not guarantee identical behaviour. Compare the exact operation, authentication method and failure semantics.

The comparison that matters

Microsoft 365 connector depth

Power Automate has first-party Microsoft connectors and is part of the wider Power Platform. That makes it a sensible default for many SharePoint, Outlook, Teams, Dataverse and Dynamics workflows.

It does not mean every Microsoft operation is present, included in every licence or suitable at every scale. Microsoft’s connector reference identifies Standard, Premium, Preview, Microsoft and partner connectors and exposes connector-specific limits and regional availability.

Make also has maintained Microsoft integrations. Its current catalogue includes Microsoft 365 Email, SharePoint Online and Microsoft Teams, with documented triggers, actions, searches and authorised API-call modules.

Do not compare connector logos. Compare the operation you need:

• Is the event instant or polled?
• Can it use the correct mailbox, site, team or account?
• Does it return the required fields?
• Does it support attachments and pagination?
• Which identity owns the connection?
• What happens when the API throttles or changes?
• Is the operation production or preview?

A connector with the right logo but the wrong trigger is not coverage.

External SaaS coverage

Make is designed around connecting many SaaS applications on one visual canvas. When a workflow moves through a website form, CRM, commerce platform, marketing tool and Microsoft 365 destination, its module catalogue and mapping experience can be a strong fit.

Power Automate is not limited to Microsoft products. It has partner connectors and can wrap public or private APIs with custom connectors. Microsoft documents OAuth, Microsoft Entra ID, API keys and other authentication routes, with private connectivity through an on-premises data gateway where supported.

The correct question is not “Does the platform integrate with third parties?” Both do.

Ask how much custom work remains after testing the exact operation.

Identity and connections

An automation often runs as the account behind its connections. That account can read a mailbox, write to SharePoint, post to Teams or update a customer system.

Before choosing either product, write down:

• the identity used by each connection;
• its permissions;
• whether multifactor authentication or conditional access affects it;
• who rotates or reauthorises the connection;
• whether the connection belongs to one person or an operational team;
• what happens when that person leaves.

In Power Automate, environment, solution, connection-reference and service-account decisions matter. In Make, scenarios, connections, webhooks and data stores belong to a team. Make’s team documentation shows that roles and monitoring capabilities vary by plan.

Never leave a production workflow owned only by the person who built the demo.

Governance and data boundaries

Power Platform administrators can use data policies to classify, restrict or block connectors and connector actions. A policy can affect design time and existing runtime resources.

That is valuable when an organisation already governs Power Platform environments. It is not automatic proof that every flow is safe. Administrators still need an environment strategy, connector classification, inventory, ownership and monitoring.

Make provides organisations, teams, roles, scenario ownership and usage monitoring. Its public security information describes encryption, external assurance and plan-dependent controls such as Enterprise SSO and extended log options.

Treat those as vendor capabilities to validate—not a shortcut around your own data review.

For either platform, ask:

• Which countries and services process the data?
• Are credentials stored and rotated acceptably?
• Can administrators discover every production workflow?
• Can they prevent an unsafe connection?
• Is activity logged for the required period?
• Can access be removed centrally?
• Does the chosen plan contain the controls being claimed?

On-premises and private systems

Power Automate supports an on-premises data gateway for supported data sources and connectors. Custom connectors can also represent private APIs through governed connectivity.

Make markets private-network capabilities in its Enterprise offering. Do not reduce this decision to “has an agent/gateway”. Test:

• supported protocols and applications;
• inbound and outbound network requirements;
• high availability;
• identity and secret storage;
• patching and ownership;
• data movement;
• plan and support requirements.

If the workflow touches a production database, involve the platform and security owners before building it.

Error handling and recovery

Neither platform can magically undo an email already sent or a record already created in a third-party system.

Power Automate offers action retry policies, conditions, Scopes, run-after configuration and run history. Make offers error-handler routes, incomplete executions and handlers such as retry, resume, skip, commit and rollback.

Make’s error-handling documentation makes an important distinction: rollback only reverts changes for modules that support transactions. Other external side effects may already have happened.

Design both platforms around:

• idempotency keys;
• correlation IDs;
• duplicate checks;
• bounded retries;
• a dead-letter or manual recovery queue;
• owned alerts;
• a runbook for replay.

A green final status can still hide a skipped record if the error route was designed that way.

Usage and cost

Do not compare a Power Automate licence label with a Make headline price.

First model the work.

In Make, an operation is a module run that processes or checks data. Bundles can multiply downstream module runs. Make now distinguishes operations from credits, and some features have different or dynamic credit behaviour. Its credits and operations guide is the correct starting point.

In Power Automate, cost depends on licences, connector tier, process/user model, hosted capabilities, capacity and the wider Power Platform agreement. Check the current Power Automate licensing guidance for the tenant rather than copying an old price table.

Measure:

1. trigger checks or webhook events;
2. records or bundles per event;
3. actions/modules per record;
4. retries and error routes;
5. child flows or subscenarios;
6. premium/custom connectors;
7. peak and monthly volume;
8. development, governance and support time.

The cheapest demo can become the most expensive production route if every input fans out into twenty billable operations or needs constant manual recovery.

Application lifecycle and support

Power Automate flows can be built in solutions with environment variables, connection references and Power Platform deployment tooling. That can be a strong fit for organisations already using managed environments and formal release paths.

Make scenarios belong to teams and can be organised, shared and monitored within the Make operating model. Before purchase, verify the export/version/deployment process your support team will actually use.

For both products, require:

• development and production separation;
• version control or a recoverable export;
• named owner and backup owner;
• documented connections and permissions;
• test data;
• rollback steps;
• operational alerts;
• change approval appropriate to the risk.

A fair eight-step evaluation

Do not ask two vendors to build different demos.

Use one representative workflow and score both platforms against the same evidence.

Step 1: Define one real workload

Example:

When a Shopify order is paid, create or update one SharePoint order record, store the external order ID, post a Teams notification and alert support if any step cannot be recovered automatically.

Specify normal volume, peak volume, attachments, sensitive fields and acceptable delay.

Step 2: Check exact connector operations

For each platform, record the trigger, every action, connector tier, authentication method and any custom API work.

Do not award a point because the app logo appears in a catalogue.

Step 3: Establish identity and ownership

Create the workflow under the intended team/environment with the planned production connections. Test access removal and connection reauthorisation.

Step 4: Apply the data policy

Confirm that the data route is allowed by Power Platform policy or Make governance. Include external subprocessors and storage in the review.

Step 5: Force failures

Test:

• expired credentials;
• an API 429 response;
• one malformed record;
• the destination being unavailable;
• a partial success after the external system has changed;
• a replay of the same event.

Step 6: Test concurrency and ordering

Send two events for the same business record close together. Check ordering, duplicate prevention and the final state.

Step 7: Measure usage

Run a representative batch and record actual actions, operations, credits, API calls and elapsed time. Project from measured numbers and include peaks.

Step 8: Hand it to support

Give a second person the alert and runbook. Can they find the failed record, understand the data, repair it safely and explain who owns each connection?

If not, the workflow is not ready—regardless of which canvas looks better.

Practical workload decisions

SharePoint approval with Teams and Outlook

Start with Power Automate. The workflow is Microsoft-first, approvals and SharePoint are central, and Power Platform governance may already exist.

Still test licensing, connection ownership, retries and approval duration.

Shopify order into SharePoint and Teams

Test both. Make may offer an attractive visual route across commerce and Microsoft modules. Power Automate may fit better if the organisation already governs all automation through Power Platform or has the required connector/licence.

Choose from the measured operation coverage and support model.

Marketing data across several SaaS tools

Make deserves serious consideration when its native modules cover the required sources and the organisation can govern the resulting team, connections and credit use.

Internal process with Dataverse and role-aware Power Apps

Power Automate is normally the more coherent route because the flow participates in the same Power Platform environment, solution and policy model.

A private API in the company network

Do not assume. Compare the Power Platform custom-connector/gateway route with the relevant Make enterprise connectivity using a security-reviewed proof of concept.

Can you use both?

Yes, but draw a clean seam.

A sensible hybrid might use Make to receive and normalise events from several external SaaS tools, then call a governed endpoint that hands a small, defined payload into a Microsoft-owned process.

Avoid a chain where Make calls Power Automate, which calls Make again, with no shared correlation ID or owner. Every boundary adds credentials, logs, retries and another place to lose the record.

Document:

• which platform owns the business state;
• the handoff contract;
• the correlation ID;
• retry responsibility;
• duplicate behaviour;
• alert ownership;
• cost on both sides.

Decision scorecard

Score each platform from 0 to 5, then multiply by the weight that matters to your organisation.

Criterion	Suggested weight
Exact connector operation coverage	20
Identity and least-privilege fit	15
Governance and data-policy fit	15
Failure recovery and replay safety	15
Measured usage cost	10
Deployment and version control	10
Support-team usability	10
Performance at peak volume	5

Change the weights before scoring. Do not change them after seeing which platform wins.

If Make fits the tested workload, you can create a Make account using Collab365’s affiliate link and reproduce the proof of concept in the correct organisation and team—not in a personal demo account.

Frequently asked questions

Is Power Automate always better for Microsoft 365?

No. It is often the natural starting point for Microsoft-first processes and Power Platform governance, but Make also has maintained Microsoft 365 integrations. Test the exact operations, identities, policies, failures and cost.

Is Make always cheaper than Power Automate?

No. Make uses credits and operations, and bundle fan-out can multiply downstream work. Power Automate cost depends on the tenant’s licences, connectors and capacity. Compare a measured production-shaped workload.

Can Power Automate connect to non-Microsoft applications?

Yes. It provides partner connectors, HTTP capabilities and custom connectors for public or private APIs. Connector tier, authentication, policy and operation coverage still need checking.

Does Make support Microsoft Outlook, SharePoint and Teams?

Make’s current official catalogue contains maintained integrations for Microsoft 365 Email, SharePoint Online and Teams. Check the exact module and permissions required rather than relying on the app name.

Can one process use both Make and Power Automate?

Yes. Use a defined handoff with one system of record, a correlation ID, owned retries and clear support responsibility. Avoid circular chains and duplicated business logic.

Want to evaluate Make with the protected Collab365 referral intact? Open the Make registration page.

If Power Automate is part of the decision, join Power Automate Builders for current, human-audited guidance on flows that other people must support.

You can also start a Make account through Collab365 when you are ready to run the same workload test there.