Integrating Dynamics 365 with Zapier and Make: when to use them instead of Power Automate

Zapier and Make exist in the same space as Power Automate: connect a trigger in one SaaS product to actions in others, without code. Both have Dynamics 365 and Dataverse connectors. Both are used, sometimes heavily, by teams that also run Dynamics 365. The question a consultant gets asked is whether that is a problem, and the honest answer is that it depends entirely on why the team reached for them and what the automation touches.

Why teams pick them over Power Automate

They already use them. A marketing or operations team with fifty Zaps connecting their web forms, ad platforms, and spreadsheets is not going to rebuild those in Power Automate because the company bought Dynamics 365. Adding a Dynamics 365 step to an existing Zap is the path of least resistance.

Connector coverage. Zapier in particular connects to thousands of niche SaaS tools that Power Automate does not have connectors for. If the integration is "when a booking is made in a small scheduling tool, create a lead", Zapier may be the only no-code option.

Make's visual model. Make's scenario builder, with its iterators, routers, and data stores, is more expressive than Power Automate's designer for branching and array handling, and some builders simply prefer it.

No Power Platform licensing conversation. A Zapier plan is a credit card decision. Premium Power Automate connectors and per-flow plans involve the licensing team.

None of those are bad reasons. All of them are reasons that lead to automations nobody in IT knows about.

Why Power Automate is usually the right answer for Dynamics 365

Power Automate is inside the security and governance boundary. It authenticates to Dataverse as the user or a service principal under conditional access, its flows live in solutions and move through environments with ALM, DLP policies govern what it can connect to, and Managed Environments give administrators visibility. The Dataverse trigger is native and fires on the change, not on a polling interval. See Power Automate connectors for Dynamics 365 and DLP policies in Power Platform.

Zapier and Make sit outside that boundary. Their Dynamics 365 connectors authenticate with a user's credentials or an app registration, and from Dataverse's point of view the automation is just an external client calling the API. Whatever that identity can do, the Zap can do. There is no DLP, no solution, and no environment promotion; a Zap built against production is a Zap built against production.

For any automation that writes to Dynamics 365 in a way that matters (creates records, updates status, moves money), Power Automate should be the default, and the burden of proof is on the alternative.

The honest cases for Zapier or Make

• Inbound lead capture from tools without Power Automate connectors. A web form, a webinar platform, a review site. The Zap creates a lead; nothing more. Low risk, high convenience.
• Outbound notifications to tools the organisation lives in. Post to a Slack channel when a deal closes. Add a row to a Google Sheet that a partner reads. Read-only from Dynamics 365, and harmless.
• Prototypes. Proving that an integration is worth building, before building it properly.
• Small organisations with no Power Platform administrator. If nobody is going to govern Power Automate either, the governance argument is weaker, and the team should use the tool it can operate.

The cases where they are wrong

Anything bidirectional. Anything that updates a record other than by creating it. Anything triggered by a Dynamics 365 change, because both tools poll the API on an interval and will eat API request allowances while adding latency. Anything with personal data leaving the tenant to a third-party platform that legal has not reviewed. Anything the business would notice if it silently stopped.

Governance patterns that work

If the tools are in use and are staying, treat them as external integrations rather than as automation platforms. Give them a dedicated application user with a minimal security role rather than a person's credentials, so that access can be scoped and revoked and so that audit logs show the automation rather than the employee. Inventory the Zaps and scenarios that touch Dynamics 365. Require that anything beyond lead capture and notifications is rebuilt in Power Automate or Azure. Review the inventory quarterly.

The identity point is the important one. A Zap running as the sales director's login has the sales director's rights, and it will keep them until someone remembers it exists.

Migration when it is time

Moving a Zap into Power Automate is usually straightforward because Zaps are simple by construction. Make scenarios with iterators and routers map to Apply to each and Condition or Switch actions, and the data store concept maps to a Dataverse table. The work is finding all of them and understanding what they actually do, which is why the inventory matters.

Stability verdict

Both platforms are stable products, and their Dynamics 365 connectors work. The instability is organisational: automations outside the tenant's governance, running on individual credentials, on polling intervals, with no promotion path. Used for the narrow cases above they are fine. Used as the integration platform for Dynamics 365 they are a liability that surfaces at the worst time. For the wider decision between platform-native and external tooling, see Azure vs Power Platform: when to use which.