Related sites:
Newsletter: Perspectives on Power Platform
Company: Niiranen Advisory Oy
I always prefer to use precise terminology when talking about the technologies that are part of my trade. Some might consider me a pedantic guy who’s always correcting some insignificant details in documents or presentations that cover Microsoft technologies but aren’t using their correct names. Yeah, the customers reading them probably wouldn’t notice the difference, but if you let go of your standards then sooner or later the lazy writing will lead to unnecessary confusion. Since I don’t write any actual computer code for a living, I guess this is my way of “debugging” the deliverables that I actually ship.
Like with actual coding, sometimes there are breaking changes introduced into the concepts that are used in technical writing, too. This happens when the product branding gets updated by Microsoft as part of their evolving commercial offering, or when existing technologies are realigned to be used in a new context. You could think of it as a new API version that MS product marketing releases, which means you need to perform updates to your “code” to keep its API references compatible with the surrounding reality. A slide deck created by Microsoft in 2016 for the Dynamics product offering would hardly pass the code validation today – yet you still see some partners out there just happily using these legacy materials in customer dialogue. Yes, I cringe a lot when seeing those.
The actual topic of this post is about what the title says: Dynamics 365 Customer Engagement is now officially gone from the Microsoft cloud. That is all. Thanks for coming, have a save ride home!
Wait, WHAT?
Oh, alright then. Let’s dive a bit deeper into the what, starting with a look back at what has happened in our earlier episodes of Microsoft business applications branding.
…And then suddenly there wasn’t. Yes, you’ll still find the term “CRM” all over my blog. I’ve had trouble deciding on what comes after it – and sticks around for longer than a year or two. Anyway, in 2016 Microsoft decided to let go of the Dynamics CRM brand and replace it with Dynamics 365 instead. There was a popular article written on LinkedIn at that time about it:
Deprecating the term “CRM” was probably a good move, but replacing it with something that didn’t specify if the technology underneath was ex-CRM or ex-AX (the enterprise ERP product) caused a bit of a mess. From that mess, the term Dynamics 365 Customer Engagement rose from the ashes of Dynamics CRM in the first half of 2017, to reference the platform that was XRM under the hood but wasn’t allowed to be called that.
A year went by and it was time to reimagine things again, with the merging of PowerApps and XRM. The platform was given the name Common Data Service, which had actually already been given to a completely different platform a bit earlier in the pre-merger world of PowerApps. Since in the cloud there are no version numbers, let’s not refer to “v1” or “v2” here either then. There can only be one CDS!
(Well, actually there were 2 after this merger still: “CDS for Apps” and “CDS for Analytics”, in short “CDS-T” and “CDS-A”, but then…) OH SHUT UP ALREADY you pedantic geek!
Summer 2018 saw the Power Platform brand emerge, and we’ve been hearing quite a lot from it since. You could say it’s been stealing the show from the previous business applications primary brand that was Dynamics 365. It would be foolish to think that we’re anywhere near the end of this Power wave that’s sweeping across the MS cloud offering.
As part of the October 2019 updates coming in the form of Release Wave 2, there have been some subtle changes to product branding for Microsoft Business Applications. For starters, MS is dropping “for” from the product names, so what used to be “Dynamics 365 for Sales” is now just “Dynamics 365 Sales”. Certification and exam names have already changed, next we’ll wait and see when the official SKU names in MS price lists will reflect this.
Another visual change you’ll see when visiting the documentation site for Dynamics 365 is that many of the apps received shiny new icons. Woo-hoo!
Then when we scroll down the page, there’s this small section with no bold graphics, dedicated to the on-premises products:
Let’s click on it, if only for old times sake. Hey, hold on! There’s actually something interesting here right on the Overview page for on-prem:
Effective October 2019, the Dynamics 365 for Customer Engagement SKU/license plan is no longer available for “online” customers. More information: Dynamics 365 Licensing Update
With this change for online customers, we are no longer using the term “Dynamics 365 for Customer Engagement apps” to refer to the collection of following apps and its related services:
* Dynamics 365 Sales
* Dynamics 365 Customer Service
* Dynamics 365 Marketing
* Dynamics 365 Field Service
* Dynamics 365 Project Service Automation
For online customers, these apps are model-driven apps running on Common Data Service. You can build model-driven apps using PowerApps. More information: What are model-driven apps?For on-premises customers, “Dynamics 365 Customer Engagement (on-premises)” is the official name of the product that provides sales, service, and marketing features. Customer Engagement (on-premises) shares many features in common with Common Data Service and PowerApps.
That’s it then. Customer Engagement is now exclusively the name of the old legacy product that you can deploy on the server infrastructure you manage. If you use anything called Dynamics 365 that’s coming from the actively developed Microsoft Cloud, then it’s not CE anymore. It’s “[Insert Dynamics 365 app name] running on Common Data Service”.
Even though some of you might feel that Microsoft keeps renaming things simply because that’s what they always do, there is a justification for the axing of the Customer Engagement brand. For those of you that work with configuring and developing solutions for the platform, you will have noticed that the cloud version resembles the old server product less and less every day. Environment administration tasks have been moving over to Power Platform Admin Center, the solution configuration work is done under make.powerapps.com, the new editors for forms, views and everything new is being introduced only to the Power side.
None of these new investments into admin and customizer tools are such that you could easily port them over to the on-premises world. There isn’t a Power Platform you could install locally, so the gap between these 2 worlds cannot ever be bridged. From a training and documentation perspective you can’t claim that “it’s all just CE, don’t worry about the small things” when the architecture of one platform no longer physically aligns with the other. CDS, PowerApps, Flow, Connectors etc. aren’t just extra pieces in the cloud, they’re an altogether different puzzle that requires new skills and fresh thinking.
Even with this line drawn, there still is support for the on-premises Dynamics 365 Customer Engagement product. The next version is expected within one year, and I’ve heard references to a 2-year update cycle for on-prem (although I struggle to find documentation pointing to such statement). Whatever the next CE version contains will most likely be more about maintenance rather than feature development. MS will not abandon the installed base of local Dynamics 365 CE environments, of course. They’ll ensure software compatibility and support up to the point that they have contractual obligations. Beyond that, it’s hard if not impossible to imagine anything new being specifically developed for on-prem, and it’s easy to see how most of the cloud stuff for CDS can’t be ported over to CE in a feasible way. None of this is big news, at least I’ve been telling it to everyone for several years already. Microsoft doesn’t state it directly, but by making Customer Engagement a separate legacy product name they’re now being as frank as they’ll probably ever be with the message.
I’ve always though that MS should have just left the server version name to be Dynamics CRM and reserve Dynamics 365 for the cloud products (like they’ve done in Office). Someone somewhere decided that bringing the 365 brand over to on-prem was a good idea, which lead to Customer Engagement now becoming the epilogue of the XRM server product’s story. At least it gives us a factual way to answer a common query from customers with on-prem environments:
“What features does Dynamics 365 Customer Engagement Online offer that on-premises doesn’t?”
The correct answer now is that this is an invalid question. There is no Customer Engagement in the cloud that you could migrate to. It’s a whole new world, founded on the Power Platform, consisting of the Common Data Service layer and the apps built on top of it by Microsoft (known as Dynamics 365) or third parties (PowerApps). Some bits and pieces are the same you find from Customer Engagement, but the products are fundamentally different.
The only constant is change when it comes to A) Microsoft product names and B) licensing model. I think that describes the general sentiment from customers and partners who’ve been participating in the Microsoft Business Applications story. I’ve got a feeling that this simply is the new reality we need to adjust ourselves to. From the business perspective, software becomes increasingly easy to consume in an on-demand fashion from the cloud, but the growing number of available apps and their possible permutations make it more and more complex to handle the higher level stuff that sits on top of the server hardware and the computer code.
In the November 2019 version of Dynamics 365 Licensing Guide there are still in total 58 references to the term “Customer Engagement”. Keep in mind that this is the document that does not apply to the on-premises products, as these have a separate licensing guide. So, all of those will need to be replaced with some other term, if MS wants to be consistent with its own branding. Ripping up the existing licensing terms and starting with new definitions isn’t quite as easy as updating the marketing materials, which might well mean that CE as a concept lives on for a while still.
Customer engagement is back! Well, to be more precise, “customer engagement apps” in lowercase. At least that’s what this August 2020 update buried in this Docs page seems to indicate:
Of course in the October 2020 update of the Dynamics 365 Licensing Guide the term “Customer Engagement” was finally removed from the licensing material. So, if you’re looking for watertight evidence on whether CE still exists or not, I’m afraid such things simply don’t exist in the world of Microsoft Business Applications product naming.
[…] CRM’s place, which has now also been acknowledged by Microsoft as they’ve essentially deprecated the CE term to refer only to the legacy on-premises software. Nor do I find myself embracing the Dynamics 365 […]
[…] the different types of licenses that have at some point in time granted access to a Dynamics 365 Customer Engagement Online environment, or CDS. Let’s copy this data into Excel for further analysis, and […]
[…] in Customer Engagement apps. (Yes, even though Microsoft product documentation says the term “Customer Engagement” is no longer used for online products, the licensing team hasn’t yet come up with a new term to replace CE in the licensing […]
Nice article. I have entered the world of Dynamics and in reading material from Microsoft was getting confused by Dynamics 365 Customer Engagement. I am confused no longer.
[…] they’ll start to challenge the Dynamics 365 applications formerly called “CRM” or “Customer Engagement”. These commercial apps from MS are nowadays just called “model-driven apps in Dynamics […]
You have turned Chaos around Dynamics 365 branding into Order and that is highly appreciated.
December 2020 and I’m responding to a highly technical, highly detailed, 956 line RFI on . . . wait for it . . . “Dynamics 365 Customer Engagement”. I’d love to send it back, saying “sorry, this is an invalid request”. But I can’t really fault them. Microsoft has done a terrible job of clearly identifying the product name changes and maintaining forward/backward naming references in it’s own documentation.