- You don’t necessarily need to buy Dynamics 365 (Dynamics CRM) licenses to get the CRM functionality you need.
- Power Apps and the Common Data Service have the components to build a simple CRM app that looks and operates *exactly* like Dynamics CRM (without the features that you don’t need)
- Dynamics 365 is a Power App
- Don’t need all that Dynamics 365 functionality? Build a CRM Power App (I will show you how)
“We need a CRM!”
I was facilitating some Power Platform training to client’s internal team the other day. This organization has Office 365 (whoops, I mean Microsoft 365), has a number of legacy SharePoint and Excel based solutions and is looking to build and revamp many line of business apps using the Power Platform. We talked about ways we could build apps using the Common Data Service, Power Automate and of course Power Apps.
We were discussing the provisioning of Common Data Service environments. Walking through the process, I noted that currently you need to specify that if you want to enable the Dynamics 365 apps at the start when you provision, and they cannot be installed later.
“Wait a minute…” came a question from one of the team. “What if we want CRM later? Does this mean we need to start from scratch and migrate our data?”
It’s a great question. However, in this case, I have a high level understanding of the organization’s business and what their ultimate objectives.
They are a non-profit organization that performs research projects and programs. Many of their initiatives are government funded. While they do have external stakeholders they don’t “sell” in a typical sense. They do collect feedback and information from their stakeholders they also do not have a customer support center or track tickets. That being said, they have a number of great use cases for model-driven, canvas and portal Power Apps.
I answered the question with a question. “What do you need Dynamics 365 (Dynamics CRM) for anyway?”
Note: Microsoft hasn’t called their suite of business applications “CRM” (Customer Relationship Management) for a few years now. However, it still is a common term for customer engagement software solutions. The “CRM” apps are now referred to as Dynamics 365, and are a collection of various apps (e.g. Dynamics 365 Sales, Dynamics 365 Customer Service and many others)
The perception in the organization is that they need a centralized repository of their stakeholders, related communications and potentially other business information.
They felt they needed a CRM system.
Despite looking at the Power Apps for some of the line of business apps, there were folks within the organization suggesting using (ugh) SalesForce.com, Dynamics 365 (CRM) or potentially some other CRM system.
My answer was that if they were to move ahead with the Power Platform, that they would essentially get most of all that functionality from the “vanilla” Common Data Model and that could expose their required “CRM” functionality in a simple model-driven (or even Canvas) Power App.
Any unique needs could be very easily added using the same tools and techniques being evaluated for building a number of other line of business applications.
This particular organization would likely never need things like Leads, Opportunities’, SLAs, Cases, etc.
It made me realize that again, maybe folks are unclear of what Power Apps and the Power Platform offers and the confusion of what Dynamics 365 offers.
The key thing to remember is this; Dynamics 365 is just a Power App.
The Dynamics 365 “first party” Power Apps provide an incredible amount of functionality for specific business cases. Sales management (Dynamics 365 Sales) Customer support management (Dynamics 365 Customer Service) as well as many others (Field Service, Project Service, Marketing, etc). that extend the Common Data Model and provide line of business applications specific to specific workloads.
Even the ERP (Enterprise Resource Planning) systems like Dynamics 365 Supply Chain Management is beginning to utilize the Common Data Model with dual-write entities.
However, not everyone needs the Dynamics 365 first party applications.
In fact, in the Dynamics CRM 3.0 to Dynamics CRM 2016 days, many projects I worked on we removed or hid many of the sales and service entities and functions and added our own. These types of apps were referred to as “xRM” or “Anything Relationship Management”.
You don’t need a CRM because you already have a CRM (and it’s a Power App).
The customer was quite relieved to know that by choosing the Power Platform, they could quickly have the CRM system they needed. The Common Data Model provided the required entities and there were already pre-built forms and views for Accounts, Contacts and Activities in the Common Data Service.
Even better was that the licensing for a Power Apps Per User plan is considerably less than a full Dynamics 365 plan license, and the license would cover both their line of business apps and CRM.
For many organizations such as non-profits, charities and government departments, a Power App can provide the core functionality required.
Even if an organization did need to eventually deploy Dynamics 365 first party apps, the hope is that someday those apps can be installed after the fact on an existing CDS environment.
Side Bar: Accelerating your Power Apps
Another great initiative by Microsoft is the creation of industry accelerators. These accelerators are built following industry standards and can be installed on both vanilla CDS and Dynamics 365 environments and do not require extra licensing. These provide customers with a head start building their industry specific line of business applications. Microsoft is adding and updating accelerators daily, check them out here https://docs.microsoft.com/en-us/common-data-model/industry-accelerators
Build Your Own Dynamics CRM 2020 in 10 Minutes
The follow are steps to build a super simple, lightweight “CRM” system on the Common Data Service using existing components. I have provided the solution files on my GitHub site, but you could very quickly build your own CRM app and extend it further for your own purposes.
Navigate to https://make.powerapps.com and choose your Common Data Service environment (or create one).
The next step is to create a solution. Solutions are the method to move your assets from one Power Platform environment to another.
In the solution, choose New -> App -> Model-driven app (this will be our new CRM app!)
Give your CRM app a name (could be just “CRM”). In my example I choose “Dynamics CRM 2020”
We need to add some core CRM entities to our app. One of the many benefits of the common data model is that it has a set of predefined entities that are core to a CRM system. Click on the Entities component.
Choose the Account, Contact and Activity entities. You could decide to add additional entities that might be useful to your organization from the Common Data Model (or create your own). For now, we are keeping our CRM system simple.
Click on “Site Map” so we can build the navigation for our CRM app.
We will add an “CRM” area. We can go back later and add other areas to our app.
Lets add a “Stakeholder” group to hold our Accounts and Contacts (Organizations and People) entities.
Add the Account entity for the sub area.
Add the Contact entity…
We will add a communications group
Add the Activities entity in the Communication Group.
Finally, save our site map and publish.
We are pretty much done. Click Done in the maker area.
In the Apps, you should now have a CRM model driven app.
Running the App, we have a model driven app with views of data, many existing functions like searching, exporting to excel, etc. It looks and feels exactly like Dynamics CRM, because, in a way, it is.
You can continue to build on this app by adding dashboards, other entities, or even adding automation using Power Automate or embedding canvas apps or building portals. You could also install some of Microsoft accelerators to get a jump start on extending your system.
If you do need some of the sales and service functions, but not necessarily all the bells and whistles of Dynamics 365, you could build these components as well or look at some ISV products like RapidStartCRM.
The point is, model driven Power Apps evolved from Dynamics CRM and should be your core CRM for your organization, no matter what you business is.
If you feel you need a CRM system for your organization, you definitely need to consider Power Apps. Not only will you have an industry standard, cloud based system that integrates with Microsoft 365 but one that can be easily modeled to your own unique requirements. In fact, if you have used Dynamics CRM in the past, you won’t even notice the difference.
Cover Photo by Karsten Würth on Unsplash
Money Photo by Micheile Henderson on Unsplash
Diskette Photo by Fredy Jacob on Unsplash
Nick Doelman is a Microsoft Business Applications MVP and has been configuring unique line of business applications built on the Power Platform before it was even called the Power Platform. Follow Nick on Twitter @ReadyXRM
33 thoughts on “You likely don’t need Dynamics CRM. You need a Power App.”
Many people know what they want without knowing why they want it or stopping to think what they need to do?
This is also a great post for Dynamics professionals to question if the customer needs Dynamics or a Powerapp.
Very well !!!!
Very Nicely Covered
Thanks very much for this awesome tutorial. I have a few questions and would appreciate if you could answer
1) I’m trying to customize the fields for contacts and can’t figure how to add a multi-select field.
2) Is there a way to automatically sync emails received in Office 365 to the timeline in the contacts of this power app?
3) Am I correct that it would cost $10 per month per user to have access to this app?
1) That’s part of a much bigger discussion, I would recommend finding resources on building model-driven Power Apps and using solutions but a quick-and-dirty way is to go to https://make.powerapps.com, click on Data (left menu) then Entities, find Contacts, click + Add Field and under data type you should see an option for multi select option set. Once the field is created, you can then add it to the forms and views.
2) Yes. https://docs.microsoft.com/power-platform/admin/server-side-synchronization (Docs refer to Dynamics 365 but it works for Power Apps on CDS)
3) Yes. https://powerapps.microsoft.com/pricing/
LikeLiked by 1 person
So I would like to thank you for this article since we started to look into power apps as it was quite intriguing to build our own CRM. Except I have been building this thing for quite a while I think around a month or 2 and the longer I am working on this CRM the longer I am thinking that it’s impossible to create it as we would like to have it.
So to show what entities we have made so far:
– Country (of course limited so all countries are entered standard for correct naming convention)
– Contact Person
– Staffel History
– Bundle Item (for when articles are bundles that contain other articles)
– App release
– App version
– App History
– Quote line
– Invoice line
– Order line
– Delivery item
, and we will probably add even more since we will need things project history, timesheets and a custom planner which will require even more entities.
We have already faced quite a lot of limits especially with calculation and rollup fields, but we managed to use flow instead of calculations for most things for others I don’t know how to do the calculation yet like calculating the balance of a project by using rollup fields on a payment entity calculation field.
Of course my idea of how Power apps works might not be correct, but I still don’t understand Power apps completely nor do I have the experience yet. Perhaps the time has come to jump into PCF and learn how it works and see if a lot of the harder parts might be solvable with custom code.
But it feels like it would take less time to build the same thing from scratch in like an Angular application, not only because Power Automate and Power Apps can be really slow from time to time but because some things tend to lack documentation like what it does how it works or can be used and if it still can be used. And especially when functionality shouldn’t be used while it still is possible to use it like workflows in business process flows which is actually replaced with the Power Automate flows. It’s even harder to find information about model driven apps since Google/Youtube shows more about canvas apps and portals then about model driven apps except for like the basics.
The main reason we are actually using Power Apps is the ability to use dozens of integrations for our CRM.
So my question am I doing something wrong or is my thinking fundamentally wrong?
PS: I am a junior developer (the only one from the company)
Many of my projects have dozens of entities as well, and growing, so no, your list isn’t unrealistic. Power Apps are quite flexible so there are many ways to do the same thing. The only thing I would advise is stuff like contacts and companies (Accounts) already exist in the Common Data Model, so you wouldn’t have to re-invent the wheel there. For many of the calculations, etc. this is where pro-dev is important and learning how to write plug-ins will address these types of requirements. As much as it might be tempting to write something custom from ground up (using angular or other) I can guarantee it will take longer. The Power Platform/Common Data Service already has mechanisms for authentication, security, some automation, user interface (model-driven and canvas) integration to Office 365, reporting and much more. Building a custom solution would require you to build those features before you even get to the business needs. I would recommend taking a look at the PL900 and PL200 certifications and related training to get a handle on the overall platform and of course Microsoft Docs and Microsoft Learn. The community is also great at providing direction/advice, etc. I hope this helps! Cheers, Nick
LikeLiked by 1 person
Thank you for your comment Nick,
So I do understand why you say not to reinvent the wheel, but I did it because I’m working in a developer environment and exporting a standard entity is no issue but you can’t import it since it already exists in the other environment. But I am glad to hear that plugins can be used for calculations. I do understand that it’s not a good idea to start from scratch since a lot that can be provided has to be made from scratch as well. Sometimes it just gives me (and forgive me for my words) a Drupal feeling (which is like Chinese to me) where they created a platform that is supposed to make things easier for the user while it actually is way more complicated than necessary and it confuses more than when you would make it from scratch (Again my apologies as this is my opinion). But I will try to do my “power” best in making the CRM and I will definitely check the certificates, training, Microsoft Docs, Microsoft Learn and the Community for information.
Interesting approach, I was wondering, if eventually the client needs to use the lead/opportunity entities and you were to add them to your custom app, they would need a D365 Sales licence right? Even if they don’t use the Sales app.
Hi Maxime, If you were to provision a “vanilla” CDS, the lead and opportunity entities would not be in that CDS. You can create your own versions, I have confirmation from Microsoft that this is OK, because the IP involved is more than just the entity for the Sales app. If you provisioned a CDS with Dyn365, but instead used Power Apps licenses, and added the CDM lead and opportunity entities to your app, as of *today* they are still considered restricted entities and would require a sales license, but that may change in the future. Also today, there is no way to install D365 apps to a vanilla CDS after provisioning (legacy code issues). That also may eventually change, but today you would need to migrate the data. I hope that makes sense, the licensing, restrictions, etc. seems to be in a constant state of flux. I just know that a lot of the smaller projects that I worked on didn’t need all the full sales or service features (or any of these features at all for XRM projects). Cheers, Nick
So why do you think people shell out twice the money perpetually for something like dynamics customer service when with a bit of up front work you can do mostly the same in power?
Thanks for the original post, I had assumed MS wouldn’t allow replication of dynamics with power, but I can see you’ve confirmed this usage with them (ref restricted entities comment).
Why use “full” Dynamics 365? If you need advanced features such as SLAs, Entitlements, Omni-channel, etc. then it would be a lot of expensive and extra work to replicate that. Another thing is that the decision-makers are not always IT-savvy, it’s a harder sell to convince leaders to buy a “platform” vs a “product” (like Dynamics 365) even though we know it’s a similar amount of work to configure. It always comes down to the most common answer “it depends”. Cheers, Nick
That’s very well explained. Great Article.
What would be your suggestion in case the business wants to use Power Apps but don’t want to be limited by the 2000 row limit (of course the collections could help). What will be right environment to choose in that scenario.
If there is a large data requirements, then there are a few strategies to get around 2000 row limit for *canvas* Power Apps. Having the data in Dataverse (CDS) you can setup views with various filters to limit the amount of data retrieved. Another option is to consider model-driven Power Apps that don’t have this limitation as they are essentially built within Dataverse (I have clients that have had millions of records). I hope that helps! Cheers, Nick
Great article Nick!
There is, however, one VERY important thing that companies should consider if they are going in the “pure” Power Apps direction. The Power Apps license does NOT include the Dynamics 365 app for Outlook. In most CRM scenarios (especially sales and pipeline mangement) the option to manually track emails and appointments is a key requirement. And since you currently can’t “upgrade” a pure CDS to a Dynamics 365 instance companies might be in for a surprice when they discover that they limited themselves from implementing that key feature of the Dynamics 365 suite.
I would properly always provision the instance with the D365 Sales Enterprice app to get all the standard entities and feature available. Then I would build my own custom Sales app using the standard entities like Opportunity and Leads. Those entities are no longer restricted entities for the Power Apps license. This way the company could start by just licensing the Power App per user license (perhaps with just one user having the full D365 Sales Enterprise license). Later as requirements increase you could just upgrade the users to the full D365 Sales Enterprise license. I haven’t been able to confirm this approach is allowed, but I haven’t seen anything in the license guide that tells me it isn’t. What are your thoughts on this?
Hi Thomas, I am getting clarification which I will post here. My understanding is that the Dynamics 365 App for Outlook *is* available for vanilla Dataverse, and considered an “app” for Power Apps per user licenses (so it would count as one of the 2 apps allowed by that license) However, the licensing guide, at times, is sometimes convoluted and contradictory. If you were planning on using Power Apps to manage sales, service, etc. then currently at this point in time, you are right in the fact that would need to migrate as opposed to upgrade, so provisioning a Dataverse with full Dynamics 365 apps (thus getting the “CRM” CDM entities provisioned) make sense. Eventually there will be an upgrade path “in the fullness of time”. However, if the purpose is truly “xRM” type applications (and this has been the bulk of my work for years) then Dynamics 365 apps add a lot of “noise” and the additional features can eat up a lot of precious capacity space. A recent (but now fixed) example is the webresources added for Dynamics 365 features that added no value to standard Power Apps that ate up 3GB+ per environment. Great question and a lot to think about. As I find out more about the Outlook app, I will add another reply. Cheers!
Thanks for you thoughts and comments. After posting my initial comment I found out that the D365 App for Outlook actually seems to be included in the Power Apps license. My issue was that the menu option for deploying the Outlook app was missing in my “pure” power app instance. After some digging around I found out that I had to download it form AppSource and enable it. After doing that I was also able to get the App for Outlook to run. It’s actually a little strange that it seems that this is included since it is named “Dynamics 365” app for Outlook. It was my initial assumption that because it had the “Dynamics 365” name it would not be included in a pure Power Apps instance. I wounder if they will change the name for at app at some point to make it less confusing? You might be right that I would have to spend the second app included in the license for Power App licensed users. Since it is a seperat app that would make sense. So for those users there would be no access to any test instance which is the primary reason that MS included access to two apps in the license. At least from what I have read.
I look forward to hearing news about any clearification you might get from MS.
I haven’t gotten “official” confirmation yet (such as a link) but confirmed with a few sources that it is included but would count as an “app” in terms of a Power Apps per App license. Since the Power Platform/Dataverse did evolve from Dynamics CRM/Dynamics 365, there are many instances where you still see “Dynamics 365” (or even CRM) in Power Apps. I will expect this to evolve over time. Ultimately, Microsoft would prefer all your users to have “per user” licenses so they have access to unlimited apps, as they would get that value. For the “per app” licenses, generally it would be targeted to end users needing access to a limited number of apps (2 + portal) on a production environment, as these users wouldn’t necessarily be doing any testing on a test environment. I fully suspect this story to evolve over time!
Thank you Nick – great article and very interesting discussion.
One reason we are still considering using Dynamics 365 Customer Service is the Omnichannel experience. Do you have any idea how to mimic its function with a “pure” Power App xRM?
Hi Markus, There is a lot of deep functionality with Omni-channel that likely couldn’t be easily replicated with Power Apps without a lot of custom development. I am not saying it can’t be done, but this might be one of those cases where using Dynamics 365 apps makes sense. As always, it comes down to requirements and how long to build vs buy/configure.
Glad I’m not the only one struggling to understand licensing. What a morass! Doesn’t help that they keep changing the terminology and licensing models just about every year. In the meantime …. because each app you develop costs an extra $10/user (or maybe $5/user, since they get two apps), there is an incentive to cram as much functionality as you can into a single app. How do you know when a totally new app is warranted? (Of course, this becomes moot when you have enough apps to hit $40/user.)
The universal answer to this is “it depends”. 😜
Ha! I could have anticipated that one. 🙂
Great article, Nick! Thanks for sharing!
Interesting discussion on the Dynamics 365 for Outlook-app as well. I’ve done the same interpretation as you, with the help of some MS-resources…
It is available, but counts as one more app. And now that the license only gives 1 app per license (not 2 as before), it would the require 2 licenses per user.
But what about the Dynamics 365 mobile client app?
Would that be available with a Power Apps-license? And if so, would it count as a third app?
E.g. a user with basic CRM-needs wants to access accounts, opportunities and activities on the web, in Outlook and with a mobile device.
Two or three PowerApps-licenses?
I am not an expert but I think that it would count as a 3rd app. Once you hit 4 apps, then the price = Power Apps per user license that gives you access to everything. I believe that might be a good question for the partner community forums on licensing (I believe MS folks monitor that). Sorry I can’t give a clear cut answer on this.
Hello Nick, very helpful CRM article, thanks a lot! I am new to Power Apps so I tested your approach and it works perfectly. What I am struggling with is e-mails.
I have already studied and searched for hours and due to MS, it should be possible to send e-mails with model driven Power Apps. I already have there e-mail entity. What I am not sure is:
1) Is it possible to send e-mails from Power App to any e-mail address (any customer email)?
2) Can I view (load) messages from my gmail account into Power App and view these messages here? Or is it neccessary to send all e-mails from within Poer App? I have already installed Gmail connector but I am not sure what to do now.
Thank you so much, Nick, for your help. Have a great day.
Hi Tomas, there are a lot of ways to send and track emails. Short answer: Yes, you can send emails from a Power App. The common way is to integrate with Exchange Online. https://docs.microsoft.com/en-us/power-platform/admin/connect-exchange-online and/or use the https://docs.microsoft.com/en-us/dynamics365/outlook-app/overview (Even though it says ‘Dynamics 365’ it will work for model-driven Power Apps.
One way that I started using in projects is by sending emails through Power Automate. You can create flows to send emails from Dataverse (e.g. contact records), either on a trigger or on a schedule.
If you are “mass emailing” (marketing type stuff) then take a look at Dynamics 365 Marketing or if it’s smaller scale, you can use Power Automate to integrate with a service like Mailchimp.
My friend Elaiza Benitez has some great videos on sending emails using Power Automate on her YouTube channel: https://www.youtube.com/watch?v=yZk1shxuYIM&t=325s
I hope you found this helpful!
Hi Nick, thank you soooo much for your response, it is very helpful to know this should work. What I wanted to achieve is just to retrieve gmail messages to my model driven power app (so user can view what messages were sent to who and when). Because I wanted to retrieve gmail (only a few messages now and then), I found out there is something called “server-side sync” option even for gmail. I actually found link in your another comment.
So I went through all the setup and it seems I successed (used OAuth 2).
But now (please do not laugh) I am not sure what to do to display those email messages in the app. I guess these will not just pop-up automatically 🙂 Thank you for your help .
I am going definitely investigate power automate too.