Work or School Accounts Now Enabled in Community!
On May 12 Work or School Accounts were enabled in Community, along with Microsoft accounts (MSA). This allows seamless navigation between Community, Dynamics 365 applications, and Azure Active Directory enabled sites while logged into your Work or School account.
Read more | Managing Accounts
Dynamics 365 2019 release wave 2 plan Discover the latest updates to Dynamics 365.Release Plan | Weekly Deployment Notes
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants.Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements.
ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Talent TechTalks
A few months ago I met an old colleague – let’s call him Ben, and we got talking. He is an experienced .NET developer now working on a greenfield Dynamics 365 project. He’d picked Dynamics up well after a few months training and upskilling himself and had a good grasp of the platforms functionality and extensibility techniques. Our conversation went something like this :
Him : I’m working on a potential 200 seat project for <financial organisation> for a Sales Process. I’m going to automatically create a lead when my custom entity changes status and allocate it to the correct sales manager.
Me : Are the sales guys using Leads at the minute or how are they tracking leads outside of D365 – spreadsheets / access / onenote?
Him : Not sure, but that’s what’s going to happen – the Business Analysts have already modelled it in our new process flow diagrams. Once the lead is qualified, we need a trigger to create a case against the related account so another team can track the lead.
Me : What is the purpose of the case? Are you sure you need to use the case entity here?
Him : It’s mainly just for tracking purposes, but the new process says we might need the ability to merge cases sometime in the future. I’ve nailed the security model for cases and leads based on our to-be business units. Dynamics is great for that.
Me : Ok,it’s good you are thinking about security. Have you considered the licences each of these users might need alongside the security rules?
Him : No, that’s not my department, my manager deals with that, I just have to design and build the solution before year end. Licences are in next year’s budget. The project needs to save the company £200k per year by year two.
Me : Hmm. Let’s discuss this in more detail.
The conversation with Ben got me thinking about my approach to initiating projects and how my approach to development and design has evolved over the years across a variety of software projects. Methodologies included :
But what about licencing? Back in the 90’s, the majority of greenfield software development projects typically involved building an application from the ground up. You needed a server, OS, web server, some sort of programming framework, throw in a database and you were good to go. SQL licensing could be tricky because of per user / per core licensing gotchas, but broadly speaking, only if the application became massively popular or successful would there be a need for new licences to be purchased in order to scale out infrastructure.
Fast forward to the almost 2020s in the cloud and it’s a bit more complicated from a licencing perspective now. It’s more important than ever for any Solution Architect to have commercial awareness and a grasp of licensing considerations alongside traditional design, development and implementation considerations. Sometimes the cost of licensing will be a major factor in how you design a solution. This is what I call Licence Driven Development (LDD).
What is LDD?
LDD is concerned with how product licencing considerations for pre-packaged business software may influence any customisation, configuration or development tasks in relation providing an overall software solution. LDD should take into account current licensing models and agreements to facilitate designing a solution which meets business requirements, balancing licence costs, implementation costs and user adoption. It should consider scope for future growth but shouldn’t involve over-specifying licences to meet potential unknown future requirements. It sits alongside any existing design and development techniques such as BDD or DDD rather than replacing them.
Three Types of Licence Driven Development Projects in the Power Platform
1. Dynamics 365 First Party Application Development
Let’s look at my friend Ben’s project. Ben has designed a solution which creates a lead. The Dynamics 365 Lead entity was designed for this use case. From talking to Ben, there is also a likelihood that Ben will use Portals, Sales, Customer Service and Field Service in the near future. From a licence perspective, the worst case scenario from a cost perspective is that he will need 200 Customer Engagement Plan licences, currently retailing at £86.70 per month per user. That’s a cool £208,080 per year before any time is spent on implementation costs. Let’s hope the out of the box implementation doesn’t need much customisation!
2. Power Platform Development
A couple of years ago, there was no other option than to pay Dynamics 365 licence costs. If Ben wanted to customise, he would have had to develop on top of Dynamics CRM or Dynamics 365 and build an XRM entity model manually. Now he has a choice. Instead of using Dynamics 365 functionality, he can build an Dynamics 365 style app himself and opt for a cheaper Power Platform P2 licence. Assuming there are 200 PowerPlatform P2 Licence users, this could bring the worst case licence cost down from over £200k to £72k per year. That will surely go some way towards saving that £200k per year.
The beauty of the Power Platform is, that since the October 2018 update, Ben is licenced to create his own ‘Lead’ entity. He doesn’t have to use that clunky one that’s a hangover from the CRM 4 and before days. Additionally, having a blank canvas to build from is easier than trying to understand the reasons someone defined an entity in a particular way (over 10 years ago). This is as a result of the following line being included in the Dynamics 365 licensing guide in October 2018 – “Custom entities may be based on entities included in Dynamics 365 or created by a customer or partner to represent business entities/items not present or to replicate those already in included in Dynamics 365.”
Currently priced at £6 and £30.50 for a P1 and P2 licence respectively, the PowerApps licences are a good middle ground licence. Both allow users to access data stored in the Common Data Service but have different interfaces. P1 provides a canvas tablet or mobile interface primarily for convenience of users performing business transactions such as requesting leave or approvals. P2 gives you the same but is closer to a traditional Dynamics 365 licence but minus the access to a set of restricted entities. With this in mind, maybe Ben could have forgone the lead and case entity and specified 100 P1 and 100 P2 licences and developed a PowerApps Canvas and Model Driven solution which could be licenced for under £40k per year.
3. Small <15 Entity App Development
So PowerApps, whether P1 or P2 is certainly cheaper than a full Dynamics 365 licence. But what if you are a small business on a shoe-string budget of £10k for year one? What if you are an SME who wants to prove that Dynamics and the Power Platform will help your business mature? What if a large majority of your users will only use your application once in a blue moon?
Assuming you have at least one full Customer Engagement licence, it’s entirely possible that there is another way you can build small applications, with what I call a ‘Foot in the door’ licence model. Take a 10 man small business primarily used by a single salesman and buy one full licence at £87.60 and 9 Team Member licences at £6 per month each. This would cost you only £1700 per year in total. From a development perspective, you can build a small application that allows all of those 9 users to use up to 15 editable custom entities.
This licensing switch to limiting team members to a fixed number of entities is a smart move by Microsoft because it has truly opened the Dynamics 365 Platform up to organisations with lower budgets. These are customers who may otherwise go with an cheap and nasty point in time solution. Now they can choose a strategic platform with a long-term roadmap. It’s reasonable to assume that a large majority of small customers who start off with Team Member licences will eventually need to upgrade higher licences. By that stage however, the benefits of the system will already be proven and cost should be less of an issue.
What approach should I take?
The answer of course is, it depends. It depends on size of company, scope of project, your maturity in understanding what you get out of the box and what you are comfortable building yourself. You may well decide on a hybrid model, using some full licences for some departments and lightweight ones for others.
Some recommendations for Dynamics 365
Whatever you do, don’t leave the licensing as an after-thought. Consider it early when deciding on your design approach and tailor your components to fit.
Business Applications communities