One of the most crucial implementation decisions you will make in the Power Platform admin centre is whether to enable Dynamics 365 applications when you are creating a new database. This is a one time decision and might cause you a lot of pain in the future if you don’t choose the right option for your needs. It affects available functionality now and in the future, and it has implications on the mix of licenses you may need.
Today I had a problem to solve, so went back to the tried and trusted method of firing up a console application to connect to a Dynamics 365 instance, to quickly run some tests to make sure that something I thought was possible, was actually possible.
In true old school style, I’ve still got a trusty boilerplate console application with a set of Nuget packages and libraries in place so I can do a variety of things quickly and easily without a lot of setup. These include log4net for logging, spkl for generating early bound code and other third party libraries and helper utilities.
The first lines of the Main method looked like this :
A few years ago, I wrote a blog about LDD – Licence Driven Development. You can read it here and hear the CRM podcast with George Doubinski discussing the concept here. It covered my thoughts at the time about how our development practices on Dynamics 365 and the Power Platform should be influenced by the Microsoft licensing guidelines. Re-reading it now, some of the conclusions seem out of date, so it seems like a good time to revisit it.
With that in mind, and based on some of my adventures in the past 18 months, here are 10 things you should consider when considering Dynamics 365 and Power Platform licencing.
During the kick-off of any new software project, a senior stakeholder will often produce a slide that explains why a high percentage of software projects fail. The intention is often to explain how the soon to be kicked off project will not fail. If you search for “Why software projects fail?”, you will find a variety of failure reasons, such as general people issues, time, lack of testing, unclear requirements, scope creep, inadequate communication, staff retention, poor risk management and more. Continue reading “Five ways to make Power Apps and Low Code Projects succeed”→
A few years ago, I wrote about ten different types of Dynamics 365 projects. One of these types of projects I referred to as a “drive-by”. A drive-by implementation is where someone, often a supplier, is interested in getting paid, and getting out as quickly as they can, leaving an implementation project to slowly fail.
Just before I started my working career, I completed a social sciences degree in Communication Studies. For the most part, this was a non-technical IT degree. It was one which made me think deeply about the day to day encounters I have with other people, written, verbal and more. With the job market not being awash with social science jobs at the time, and having hacked around a lot with BBC Basic on an old BBC Micro and Acorn Archimedes in my formative years, I felt a pining for programming again, so I forged a career in the IT industry. I’ve been here ever since. Continue reading “Five ways to become a Software Engineering Multiplier”→
Are you starting a new Power Platform or Dynamics 365 Project and not sure where to start or how to frame the requirements?
Here’s a short explainer video I’ve created to get you thinking about the reasons for building a prototype and what you can hope to achieve through building one and demonstrating it to your prospective users or business stakeholders.
I normally do my weekly grocery shopping online, however since the Coronavirus lockdown and because of the shortage of home delivery slots, I have the first world problem of visiting the supermarket again in person! After returning from a shopping trip this week, I saw a meme on twitter which reminded me of the dilemma most supermarket shoppers face after unpacking their shopping into their car – namely looking at the empty shopping trolley and wondering where to return it to. To quote the tweet :