Dynamics 365 Customer Engagement (CE) is Microsoft’s CRM platform — but calling it “a CRM” undersells what it actually is. Under the hood, D365 CE is a set of model-driven applications (Sales, Customer Service, Marketing, Field Service, Project Operations) built on top of a shared data platform called Dataverse.

That distinction matters because almost everything you’ll do as a developer or consultant happens at the Dataverse layer, not inside any one app. Tables, relationships, security roles, business rules, plugins — all of it lives in Dataverse. The “Sales” or “Customer Service” app you open is really just a curated view (a sitemap, a set of forms, a set of security roles) over that same underlying data.

Where D365 CE fits in the Microsoft ecosystem

Microsoft’s “Dynamics 365” brand actually covers two very different product families, and mixing them up is a common early mistake:

  • Dynamics 365 Customer Engagement (CE) — Sales, Customer Service, Marketing, Field Service. Built on Dataverse. This is what this site covers.
  • Dynamics 365 Finance & Operations (F&O) — Finance, Supply Chain Management, Commerce. A completely different technical stack (X++, its own data model), aimed at ERP scenarios.

They share a marketing name and can be licensed together, but a D365 CE plugin developer and an F&O developer are doing almost entirely different jobs.

Dataverse: the foundation

Dataverse (formerly the “Common Data Service”) gives every D365 CE environment:

  • A relational data store — tables (entities), columns, and relationships
  • A security model — business units, security roles, teams, field-level security
  • A business logic layer — business rules, workflows, Business Process Flows, and plugins
  • A Web API for programmatic access from code, Power Automate, or external systems

Because Power Apps (canvas and model-driven), Power Automate, and Power BI all read from the same Dataverse, a table you create for a CE project is immediately usable by a canvas app, a Power Automate flow, or a Power BI report — no separate integration required.

Why this matters in practice. When a client asks “can we also build a mobile app for our field techs” or “can we get a Power BI dashboard on this data,” the answer is usually yes with very little extra work — because it’s the same Dataverse underneath. This is the real selling point of the platform, more than any individual app.

The standard apps, briefly

  • Sales — leads, opportunities, quotes, orders; the classic CRM sales pipeline.
  • Customer Service — cases, knowledge base, SLAs, entitlements.
  • Marketing — customer journeys, segments, email marketing.
  • Field Service — work orders, scheduling, resource management for on-site technicians.

We’ll cover Sales, Marketing, and Customer Service in more depth in the Core Modules course. For now, the important takeaway is: these are configurations and conventions on top of Dataverse, not separate products with separate data.

What this means for how you’ll learn the platform

Because the real platform is Dataverse, this course path spends most of its time there: tables and relationships, forms and views, security roles, business rules and process automation, and — later — writing plugins and calling the Web API. Knowing “Sales app” menu paths matters far less than understanding how Dataverse itself is structured, because that knowledge transfers across every app and every project.