Power Apps vs Dynamics 365 CRM

By Emil Björk · Microsoft business apps consultant, Gothenburg

Both run on Dataverse, both let you build business applications. When to buy Dynamics 365 Sales / Customer Service / Field Service, when to build a custom Power App, and when to do both.

Updated 2026-08-27

"Should we build a custom Power App or buy Dynamics 365?" comes up in every Microsoft business-apps conversation, and the honest answer is that they solve overlapping but different problems. Both run on Dataverse. Both use the same tools to extend. But one ships pre-built with sales / service / field-service processes baked in, and the other is a blank canvas.

This guide walks the decision in the shape it takes in real deals.

What each actually is

Dynamics 365 CRM (Sales, Customer Service, Field Service, Marketing, Customer Insights, Project Operations) is a collection of pre-built model-driven Power Apps on top of Dataverse. Microsoft configured the tables, the relationships, the security roles, the business process flows, the workflows, the dashboards, and the mobile experiences for the specific business processes each app targets. You buy the app, get a working starting point on day one, and configure or extend it to fit your business.

Power Apps is the platform underneath. A custom Power App is a Power App you build yourself — either canvas (drag-and-drop pixel-perfect designs with Power Fx formulas) for task-specific workflows, or model-driven (data-centric UI generated from Dataverse metadata) for record-heavy processes with security roles and complex forms. You get a blank Dataverse environment and build whatever you want on it.

Architecturally the two are identical below the app layer. Extending Dynamics 365 uses the same tools, the same solutions, the same Dataverse, the same governance as building a custom Power App from scratch.

When to buy Dynamics 365

Buy Dynamics 365 when the business process you're implementing matches the shape of a shipped app:

  • Sales. B2B pipeline management, opportunity tracking, forecasting, quoting, Copilot for Sales inside Outlook.
  • Customer Service. Case management, omnichannel, knowledge management, SLAs, entitlements, agent copilot.
  • Field Service. Work orders, scheduling, mobile technician app, connected assets, IoT.
  • Marketing / Customer Insights - Journeys. Customer journeys, email marketing, event management.
  • Project Operations. PSA — opportunity to cash for services firms.

The shipped apps carry decades of learned best practice about how these processes work. Rebuilding an opportunity-to-close pipeline in a custom Power App is possible but wasteful — you spend a year recreating what Sales gives you on day one, and the year of feature investment you'd have needed to keep it competitive with Sales' quarterly Wave updates never happens.

When to build a custom Power App

Build a custom Power App when the process is specific to your business and doesn't map to a shipped app:

  • A field-inspection app for a specific regulated industry — inspection templates, photo capture, compliance sign-off — that doesn't fit Field Service's work-order model.
  • A manufacturing floor tracking app for a specific production line — barcode scan, batch attributes, custom quality gates.
  • An internal-approvals app — travel requests, capex approvals, procurement pre-authorisation — that's uniquely shaped by your policy.
  • A customer-facing portal on Power Pages that doesn't need Dynamics 365's back-end.
  • A legacy-system-front-end app that surfaces data from an on-prem system through virtual tables without duplicating it into Dataverse.

The pattern: highly specific to your business, low overlap with any shipped CRM app, and a working prototype in 2-4 weeks with a small team.

When to do both

The common pattern is Dynamics 365 for the core CRM process, custom Power App(s) for the adjacent workflows the CRM doesn't cover naturally.

A field-service business runs Dynamics 365 Field Service for work orders, dispatch, and mobile technicians, then adds a custom Power App for the pre-work customer-site-audit workflow that Field Service's data model doesn't fit cleanly. Both apps share the same Dataverse, the same Account and Contact records, the same Copilot layer. The custom app is not "instead of" Field Service — it's alongside it.

The custom app benefits from Field Service being there: shared identity, shared master data, shared reporting. Field Service benefits from the custom app being there: the customer's full pre-work data is on the customer timeline for the technician to reference.

The economics

Dynamics 365 CRM is per-user per-month at a real price point. Sales Enterprise is around $95/user/month; Customer Service Enterprise similar. Attach licensing reduces the second-app cost.

Power Apps licensing is either per-app (approx $5/user/month per app) or per-user (approx $20/user/month for unlimited apps). Substantially cheaper per user than Dynamics 365, but you also get less — you're building the app yourself.

For a custom app that would replace Dynamics 365 Sales, add up the build cost (engineering time to build, plus the feature investment you'd need to keep it competitive over five years) against the licence saving (approximately $75/user/month × user count × 60 months). For most sales-org sizes the build cost dwarfs the licence saving.

For a custom app in a workflow Dynamics 365 doesn't cover, the licence saving is real because there's no Dynamics 365 licence to buy in the first place.

The failure modes

Two common failure modes deserve calling out.

"Let's build custom because Dynamics 365 is too much." This is the argument to run away from features you'll wish you had in a year. Sales' forecasting, sequences, sales accelerator, Copilot for Sales — these are years of Microsoft investment. If your process fits Sales, use Sales. The "we'll build a simpler version" instinct almost always ends with the custom app slowly growing to match what Sales already does, at your cost.

"Let's buy Dynamics 365 because Power Apps is too complicated." This is the argument that shows up when the actual business process is genuinely unique. Dynamics 365 was configured for the typical sales / service / field-service workflow. If your workflow deviates materially — different data model, different lifecycle, different UX — you fight the shape of Dynamics 365 to force it to fit, and every quarter's Wave brings changes that break your customisations. Better to build the custom app that fits the process.

The decision is not "how sophisticated am I" — it is "does my process match the shipped app's shape."

The short version

Dynamics 365 CRM = pre-built Power Apps for sales / service / field-service. Power Apps = the platform underneath for building your own.

Buy Dynamics 365 when your process matches a shipped app. Build a custom Power App when your process is genuinely specific. Do both when there's a core CRM process alongside adjacent workflows that don't fit the shipped app. Don't build a custom replacement for a shipped app unless you're prepared to fund the feature roadmap yourself.

Frequently asked questions

What is the actual relationship between Power Apps and Dynamics 365 CRM?

Dynamics 365's CRM apps are pre-built model-driven Power Apps on Dataverse. Buying Dynamics 365 buys you Microsoft's configuration of tables, security roles, process flows and dashboards for a specific business process. Building on Power Apps means starting from a blank Dataverse environment.

How do the license costs compare?

Dynamics 365 Sales Enterprise is around 95 dollars per user per month; Power Apps is roughly 5 dollars per user per app or 20 dollars per user for unlimited apps. Power Apps is much cheaper per seat, but you are building — and maintaining — the application yourself.

When is building custom a mistake?

When your process actually fits a Dynamics 365 app. Forecasting, sequences, the sales accelerator and Copilot for Sales represent years of Microsoft investment; a 'simpler custom version' almost always grows back toward what Sales already does, at your cost.

When is buying Dynamics 365 the mistake?

When the workflow deviates materially from the typical sales or service shape — different data model, lifecycle and UX. Then you end up fighting the shape of Dynamics 365, and release waves keep breaking your workarounds. Build the app that fits the process instead.

Further reading

Related guides

Spot something wrong or want a topic covered? Send a correction or a topic request — both are welcome.