Customer Service Professional versus Enterprise

What it does

Professional and Enterprise are two named-user subscriptions for the same Customer Service app family. Professional is the cut-down seat aimed at simpler service operations; Enterprise is the full one, and it is the floor for entitlements, knowledge, routing rules and anything omnichannel. Most of the feature split lives in the Dynamics 365 Licensing Guide rather than on Microsoft Learn.

Key facts

Both are per-user subscriptions bought and assigned in the Microsoft 365 admin center. The feature-by-feature comparison is only published in the Dynamics 365 Licensing Guide PDF (go.microsoft.com/fwlink/?LinkId=866544) — Learn pages consistently defer to it rather than restate it.
Learn does publish one hard, checkable part of the split: the restricted tables list. Case (incident) and SLA (sla) can be created, updated and deleted by either Professional or Enterprise users.
Entitlement (entitlement), Knowledge Article (knowledgearticle) and Routing Rule Set (routingrule) require Customer Service Enterprise (or a Customer Engagement/Dynamics 365 plan). Professional does not grant write access to those tables.
Restricted-table enforcement applies to create, update and delete only. Read is open to anyone with a standard Power Apps or Power Automate licence, which is why reporting and integrations often look fine right up until they try to write.
The Case table has a documented exception: a Power Apps or Power Automate licensed user can create cases and manage only the ones they created themselves. Useful for self-service front ends, useless for agents.
You cannot mix Enterprise and Professional users on the same instance. Microsoft states this as a contractual requirement, not a technical block — nothing in the product stops you.
App access is gated by service plan. A user without the right plan gets error 2147812097, and the message names the exact service plan the app module wants.
The environment itself must be created with Dynamics 365 apps enabled. A Dataverse-only environment will refuse the Customer Service app install no matter which seat you hold.
Customer Service Premium is a third named SKU alongside Professional and Enterprise in the admin center, not a variant of either.

When to use / skip

Professional makes sense for a small internal helpdesk that logs cases, applies a simple SLA and does nothing else — no knowledge base, no entitlements, no queues driven by routing rule sets, no chat or voice, no Copilot. That is a narrower box than most clients imagine when they hear the word "professional", and the moment someone asks for a knowledge base you are having a different conversation.

In practice, almost every service project with a customer-facing dimension lands on Enterprise. The instance-level mixing restriction is what usually decides it: if any part of the business needs Enterprise features, the whole instance goes Enterprise, and running a separate Professional instance for the cheaper population costs you an integration and a second ALM pipeline. That is rarely worth the seat saving.

Skip the debate entirely if omnichannel is on the roadmap. Chat, SMS, voice and unified routing sit at Enterprise and above, so Professional is a dead end you will pay to leave.

Configuration decisions

Which edition the instance runs on — this is an instance-wide call because of the no-mixing rule, not a per-user one.
Whether the read-mostly population is covered by Team Members, a Power Apps per-app plan, or a portal rather than a second Customer Service seat.
Whether knowledge management is in scope, since that single answer usually settles Professional versus Enterprise on its own.
Whether any integration or automation writes to entitlement, knowledgearticle or routingrule under a named user identity, and what that identity is licensed as.
Whether you split into two instances by edition, and if so who owns the contact/account master between them.
Which service plan the app modules you build actually require, if you are shipping custom apps alongside the first-party ones.

Gotchas

The mixing rule bites at audit, not at deployment. Nothing prevents an admin assigning a Professional seat into an Enterprise instance, so the breach is invisible until someone asks for a licence position.
Restricted-table write failures show up as permission-shaped errors in flows and integrations, and people burn days on security roles before anyone checks the licence.
Read access being unrestricted makes Professional look more capable than it is during a demo. You can show a knowledge article; you cannot author one.
Buying Professional to save money and then discovering routing rule sets are Enterprise-only is a common and expensive mid-project reversal.
Licensing guide contents move between release waves. Any feature split you wrote into a design document twelve months ago needs re-checking before you rely on it.
Trial environments are provisioned with Customer Service Enterprise, so a proof of concept built on a trial will not reflect Professional limits at all.

Consultant notes

Get the client's actual licence position from the Microsoft 365 admin center before designing anything. Do not accept "we have Customer Service" as an answer — ask which SKU and how many.
If the client is on Professional and wants knowledge, demo it on a trial and be explicit that the demo is running on Enterprise. Set that expectation before the wow moment, not after.
Push back hard on any plan that mixes editions in one instance. Frame it as a contractual exposure, since that is what it is.
Before go-live, run a pass over every flow, plug-in and integration that writes to Customer Service tables and confirm the identity behind each one is properly licensed.
Keep a dated copy of the licensing guide you designed against. When Microsoft changes the split, you want evidence of what was true at the time.

Worth another look after the next release wave, or whenever Microsoft republishes the licensing guide and quietly moves a feature between editions.