What the heck are we supposed to call Microsoft’s online CRM platform anyway?

Ah, CRM. If you have lived in Dynamics CRM land for a long time, you know exactly what I mean when I say CRM. It used to be pretty simple; It’s Microsoft’s CRM product: Dynamics CRM. Then Microsoft branding and marketing got involved and we got a long ever-changing road of really confusing terminology.

In case you’ve been living under a rock… or you know, think of Dynamics as a brand of ERP products (we’ll get to that later), CRM stands for Customer Relationship Management. Essentially, if you are a business, and have customers, then you need a CRM system. Depending on the size of your business, that might just be a black book, or a series of Excel spreadsheets, or a database of some kind. A first-class CRM product would be called for if you have salespeople who need to track contacts, accounts, sales and opportunities. You might also need one to track customer service cases or to manage marketing campaigns.

In any event, Dynamics CRM started as a first-class CRM product that just happened to be very customizable (perhaps “xRM” rings a bell?). You could use it as just a CRM (you know, like Salesforce), or you could customize it to do almost anything you want with it (I’ll get to that later too). We always just called it “CRM”. That’s it. Not “Dynamics CRM” or anything like that, Just “CRM”. Everyone knew what we were talking about.

So when did the confusion begin really? Well originally, Dynamics CRM was on-prem. Fast forward to a few years ago (please don’t tell me it’s been almost 10) and Microsoft decided that like literally everything else that exists now Dynamics CRM would be offered in the cloud as SaaS. At first, the online version was called “Microsoft Dynamics CRM Online”. Nice.

Things were simple until it was decided in 2016 to rebrand CRM under the Dynamics 365 umbrella along with several different ERP products. CRM would appear in this suite of software – along with the ERP products AX and NAV – but wouldn’t be called CRM anymore. Instead you had a few different busniess apps – “Dynamics 365 for Sales”, “Dynamics 365 for Customer Service”, etc. Each of these apps was just CRM but with a narrow sitemap containing only the module in question. Of course there were also apps like “Dynamics 365 for Finance” which was NAV under the hood or “Dynamics 365 for Operations” which was AX under the hood. In terms of licensing you didn’t get a license for CRM as a whole anymore, instead there were different Dynamics 365 plans which included different apps from this unified selection.

In a way it did all make sense from a marketing perspective; since the desire was to mainstream the Dynamics products that had previously been under a different business umbrella. A popular blog post from 2016 compared it to when they bundled a bunch of previously separate products like Word, Outlook, PowerPoint and Excel into “Office 365”. Instead you have a bunch of previously separate products that collectively are called the same thing – Dynamics 365. The difference really is that with the Office 365 product the separate apps are still called the same thing that they were before they were bundled. Word is still Word, Excel is still Excel. With Dynamics 365, you didn’t have a direct line of naming succession, and CRM was now called different things depending on the business application.

Further to all this, Dynamics CRM had for some time been pushed as a more than “just” a CRM application. It had been pushed as a platform. Some of you may have been around long enough to remember this:

CRM was actually xRM. Meaning that it was a platform that you could build a wide range of business applications on top of that went way beyond just CRM. Dynamics CRM was highly customizable and was in fact a great platform to serve this purpose. It was so robust that we even built a Portal product to sit on top of it and allow businesses to engage with their customers at a whole new level. Well, now that platform with all those applications and the Portal and all that…doesn’t officially exist anymore. Sure it still exists under the hood of Dynamics 365 Sales, Dynamics 365 Customer Service, and so on, but what should we call the platform now? Just “Dynamics 365”?

Here’s the thing. If you find yourself attending D365 community events or UG events, or worse still if you work on projects that have both a CRM and ERP element to them and D365 is the selected platform, you might bump into the situation were you start up a conversation with someone about Dynamics 365 and very quickly realize that you are speaking different languages. To the ERP person “Dynamics 365” means the ERP product. Dynamics 365 IS an ERP product to them. For you, it’s the opposite. When you say “Dynamics 365” what you really mean is “CRM” but you can’t say that anymore. Or you know, you could say screw it and keep calling it CRM anyway.

Realizing that there had to be some way of distinguishing the portion of Dynamics 365 that came from the platform that had been CRM, Microsoft decided in 2017 to introduce the name “Dynamics 365 Customer Engagement” to refer to the product that had been CRM but wasn’t allowed to be called that anymore. All was well. Soon the confusion started to abate. We had “Dynamics 365 Business Central” for “BC” for short, and that was the new name for NAV online. Then you had “Dynamics 365 Finance & Operations” and that was the new name for AX. And of course you had CE for CRM. So now you just had to get over the habit of saying “Dynamics” (or CRM) when you meant “CE”. Easy.

That is until Microsoft officially announced that CE is gone from the Microsoft cloud. The apps are still there, but they won’t be referred to collectively as “customer engagement” anymore. Instead we are back to them not really having a collective name and just being separate D365 apps again.

I kid, I kid…

So why the change? CE was a perfectly good name to describe the online CRM offering no? Of course there is a problem with this. CE is the name for the online version of the CRM product, right? Well, increasingly, the online product isn’t really the same product as the on-prem product anymore – it’s not even built on the same foundations. Under the hood, the underlying platform has shifted from what was CRM to what is now the Power Platform. No one explains it better than Nick in his amazing blog post explaining the Power Platform. Long story short – we got xRM, but in the form of the Common Data Service, and Dynamics 365 apps are just vertical apps built on this service. It’s all part of the power platform. So, there is no distinct CE product that is separate from the Power Platform anymore – least not for much longer from a tech or infrastructure perspective.

CE is now the name for the on-prem product. CRM is truly gone. Meanwhile, we are still stuck trying to figure out how to refer to “the set of model-driven premium business apps that you pay separate licensing costs for that aren’t ERP”. Or in other words “the CRM stuff”. Well, for now at least, the correct way to reference any of the individual apps is “[Insert Dynamics 365 app name] running on Common Data Service”, so for example “Dynamics 365 Sales running on Common Data Service”. Yes, that’s a mouthful and also notice there is no “for” in the title anymore. Therefore, as a whole, the set of apps should be called “Dynamics 365 apps running on Common Data Service”.

That all said, I might suggest a better name: wait for it.

Dynamics 365 Power Apps

*applause*

Hope you enjoyed the read! I’ve been gone for a while but hope to post more frequently again and will be making some updates to my site. Stay tuned, like and share!

Portals have come a long way since Adxstudio’s xRM Framework

In case you haven’t heard, the Microsoft October 2019 Release plan has some pretty huge news when it comes to Portals – They are going to be put on center stage as a first-class app type along with Canvas Apps and Model-Driven Apps.

Starting soon, when you go to web.powerapps.com and go to create a new app, in addition to Model-driven apps and Canvas apps there will be a third type of app: Portal!

These Portals will be exactly the same as the previous portals, but you don’t need dynamics CE anymore. These Portals run off of the Common Data Model (just like before, really). In fact, you’ve been able to see the CDS portal in action for a while now. Now, Dynamics CE is still an important vertical to consider, so in a future post we’ll look at when you should skip CE and when you should still include it in your solution.

Portals are going to now be open to a much bigger audience as people jump onboard the power platform. With PowerApps, you can built out purpose-driven applications to suit your business needs – no longer are we modifying a CRM system to implement a system that doesn’t really have anything to do with CRM. Naturally, Portals are a key part of that story and the technology used to build Dynamics portals is being brought forward as the missing part of the puzzle. This feels so rewarding as all the work that my colleagues and I did at Adxstudio back in Regina, Saskatchewan at the old park street office building Portals has really come to full fruition.

Let’s rewind to 2009. I had just completed my Master’s Degree – well, scratch that – I was close to completing my degree and decided to start working full-time while I finished up the last “month or two” of my thesis. Actually finishing and defending my thesis would take well over an additional year, but that’s another story.

You see, I had accepted a fantastic offer for a brand-new developer from a local company in Regina, SK called Adxstudio. I started off right out of the Gate as a Developer on the Product Team working on little product called the xRM framework, which was nearing completion of version 2.2 when I came on board.

Most of Adxstudio’s business came via it’s other product, a Content Management System (which was a big deal at the time) simply called Adxstudio CMS. It was a fine piece of software, but most of our investment was in Microsoft Dynamics CRM, which had recently released version 4. We believed that Microsoft Dynamics was the future – and we were all in. What we had developed was a framework which allowed developers to interface easily with Dynamics CRM without interfacing with the SQL database directly. The primary use case for this was to integrate a website withe Dynamics 365, so that records such as contacts from CRM could be surfaced in some way on the website. Sound familiar?

Included was an authentication model that allowed you to log in and have your user associated to a Contact in CRM. It also had a fully functional CMS allowing you to manage the website via Web pages, Web Links, Content Snippets and so on. We developed a few different websites too – we didn’t call them portals yet – such as the Company Website, branded Wireframe Industries – boy I wish screenshots from back then survived – the Conference Website, which used the amazing technology of Silverlight, and Community Website, which added some baked in features such as Blogs, Ideas and Forums.

Well as Dynamics CRM 2011 came out the door, we made the decision to give the xRM framework base code to Microsoft. It became part of the official Microsoft CRM SDK. This was rewarding it it’s own way but put us at an advantage because now the best way to surface data from CRM onto a website was to use a Portal using our framework. You could do some basic stuff for free using Microsoft’s accelerator portals, or starting from scratch using the framework that came with the SDK, but if you really wanted to play with power, you could use our product, which we kept adding features such as Web Forms, and later Entity Forms, Entity Lists, and finally Entity Permissions to. This product was finally named Adxstudio Portals (v4 of the xRM framework).

As Dynamics went through releases over the years so did Portals. With version 5 the solution layering was completely redone from scratch – manually, by me at first (!) – while we refined our ALM processes (and eventually came out with a great toolkit called the ALM toolkit to help automate the process ). With version 6 the front-end was completely redone to use bootstrap and Entity Permissions were added. With Version 7, we added liquid support which radically changed how customization of the Portals was done. It was now ready for the cloud.

And with that, Microsoft announced the acquisition of Portals (and the Adxstudio brand). I had the privilege of working with their new Portal product team to help integrate the Portals into their product lineup. Version 8 of Portals, as we called it internally, would soon be released as Dynamics portals – a fully in-the-cloud solution that extended Dynamics 365 for Customer Engagement.

Fast forward to today, and finally we are able to do the things with Portals that we saw ourselves doing with it way back in the days were we used “xRM” as a buzzword. I can’t wait to work on many more Portals implementations and I’m interested to see where we go from here.

Thanks for reading,

A Closer look at Entity Forms and Entity Lists created by the Create Portal Content Wizard

In my post about the Create Portal Content Wizard, I talked about how easy it is to add content to the portal using point-and-click configuration, and demonstrated that the Wizard creates a whole lot of records in the background for you so that you don’t have to. It’s like magic! It certainly does beat having to spend the time configuring Entity Forms, Lists, Permissions, and web pages all from scratch. However, the Wizard also has its limitations. There are several scenarios that it simply can’t manage, including some fairly basic ones. The Wizard can also leave you with a fair bit of manual work or cleanup to do, depending on what you’re building.

In order to better understand the Wizard, I figure now’s the time to spell out exactly what records actually get created by the wizard. To do this, we’ll go through the different options for configuring a list (we care mostly about displaying organization entities, so that’s the focus of this article) and then see exactly what configurations are created with each and what changes occur with the different settings. If you aren’t familiar with the Wizard, I explain the steps for using it here. Read that first, then come back – this article is more of a deep dive.

Continue reading “A Closer look at Entity Forms and Entity Lists created by the Create Portal Content Wizard”

Building the Perfect Portal Team

Recently I participated in a group discussion with Colin Vermander about what it takes to have a successful implementation of Dynamics 365 Portals. Among many other factors that I’m sure we’ll discuss in the future, one that struck me is how to build the perfect Portals Implementation team

I thought it would be fun to take a look at the skillsets that are needed to build that team, and the roles associated with those skillsets. Now let’s make the distinction clear before we get started that many of these roles overlap, and the people who fill these roles simply need to have the skillsets required. Very often, one person might fill multiple roles on a smaller project. For example, the Business Analyst and Functional Consultant might be the same person. Conversely, on large implementations with tight deadlines, you might have a very large team with multiple workstreams. Each workstream might have a team of BAs, its own dedicated functional, solution architect, and development team. The golden rule at the end of the day is to ensure that the project is not understaffed, and that each of the below skillsets is taken into consideration when building your team.

Also note, that this article tries to be methodology-agnostic as much as possible. Some roles might only apply to certain methodologies – for example if you are using scrum you’ll need a scrum master, etc. Alright, without further adieu, let’s get down to it.

Continue reading “Building the Perfect Portal Team”

Basic Portal Entity Permissions and the Create Content Wizard

In the last article I wrote on this subject, we talked a bit about the Create Portal Content wizard. In that article, we walked through creating a list of leads that displays on the portal. Anyone can access the list, and it’s read-only. Where can we go from here?

Perhaps we don’t want to allow any anonymous users to see our lead list because we only share this information with partners, for example. In this case, we want the ability to create new leads or edit existing leads from the portal, or to take actions on those leads. In other words, we want a secure list of leads that can be modified by those with the appropriate permissions.

For now, let’s not worry about the realism of this scenario.  In a future post, I’ll show you how to build out an awesome portal, and we’ll look in more detail at a realistic business use case at that time. For now, let’s use this simple example to build our knowledge of how to manage permissions for entities exposed on the portal.

Continue reading “Basic Portal Entity Permissions and the Create Content Wizard”

Embedded Canvas Apps within Model-Driven Forms

Just this past December, Microsoft announced the ability to enrich model-driven forms with embedded canvas apps – and this is really exciting. Since I first started working with the power platform, the fact that canvas apps and model-driven apps don’t really play together has seemed a notable limitation. This enhancement really helps bring everything closer together because we can get the same pixel-perfect purpose-driven UI that we’ve come to love (and we all know we do) about canvas apps but within a fully functional model-driven application. In case you are wondering, yes this does potentially open the door to embedding canvas apps within UCI for Dynamics 365 as well (since UCI for Dynamics is essentially a model-driven app).

First off, it takes only a few clicks to embed a canvas app on a model-driven form. Canvas apps are easy to develop (hence the somewhat-maligned concept of the citizen developer) and you can craft very nice visual layouts with “no coding” required (in fact it’s the same level of coding that you’d be using with custom excel apps for example). Furthermore, to bring in and display data from external services, you can choose from a long list of connectors that PowerApps offers for popular services such as SharePoint and Office365 or they can create custom connectors. Finally – and this is important – you get the context of the model-driven form passed in to the canvas app – including the current record or list of related records.

Continue reading “Embedded Canvas Apps within Model-Driven Forms”