As I think back to past customers of Dynamics 365, not all of them were successful. The challenges that brought them to Dynamics 365 were real enough, but at the time we only had one solution to try and solve them with. I would love to snap my fingers and take Power Apps back in time. Sledgehammers Dynamics 365, borne out of it's predecessor, Dynamics CRM Online, is a software marvel. I'm talking specifically in this post about the "CRM" side of Dynamics 365. For a midsized to large...
As I think back to past customers of Dynamics 365, not all of them were successful. The challenges that brought them to Dynamics 365 were real enough, but at the time we only had one solution to try and solve them with. I would love to snap my fingers and take Power Apps back in time.
Sledgehammers
Dynamics 365, borne out of it's predecessor, Dynamics CRM Online, is a software marvel. I'm talking specifically in this post about the "CRM" side of Dynamics 365. For a midsized to large business, D365 has all of the tools you would need to transform your entire operation. XrM was a blessing and a curse. In layperson's terms, XrM was the capability to customize almost any of the significant out-of-the-box capabilities to meet organization specific needs in a highly targeted and relevant way. XrM was also the path utilized to "Extend" D365 to solve other problems not contemplated by the out-of-the-box capabilities. It is a powerful combination that can be brought to bear on almost any business problem.
The Curse
Over the years, many Dynamics 365 partners became very proficient with XrM. As a result, D365 became a solution to "anything", not just Sales or Service related issues. When your only tool is a hammer, every problem looks like a nail. A customer has a business issue, not related to any of the out-of-the-box capabilities, no problem, we can solve it with XrM! And so it begins, provision an instance, hide most of the out-of-the-box capabilities, and start building custom capabilities. Or, maybe to save some time, we'll re-purpose some of the OOB capabilities, and contort them to fit the requirements, sorta. It's one thing to modify the Opportunity capabilities to better fit a customer's specific Opportunity requirements, even if modified heavily, it's another thing to re-purpose the Opportunity process to solve for Asset Tracking. As a result there are a lot of "bastard" deployments in the wild.
Commitment
Many well-intentioned partners, offered D365, planning on extensive use of XrM, as a solution to many customers' non-sales or service related problems. Could it solve those problems? Yes! But never as easily, or quickly or cost efficiently as anticipated. Trying to build a custom solution within D365 to a unique problem, is like doing laps in a crowded pool. Your route from start to finish will end up being far from a straight line. For some customers the cure was worse than the problem. All partners have experienced the customer who eventually pulled the plug on the effort. Wouldn't it be nice if there was a way to get the XrM capabilities in an empty pool?
Power Apps
Over the past couple of years Microsoft has been rolling out Power Apps, now part of the Power Platform. You may have seen it pop up in your Office 365 environments, you may have even played with it. That is really one face of Power Apps. Microsoft, in their infinite wisdom decided to use the same "Power Apps" name for another, completely different, solution. I personally put this at the top of my Dumb Decisions list... but that's another story. The Power Apps you might have seen or used in Office 365 are what are called "Canvas" Power Apps. If you look at a SharePoint list online, for example, you may have seen the Create Power App button, which if clicked, will automatically create a "Canvas" Power App from your list. As a result, a significant number of customers feel they are familiar with Power Apps, I know because I talk to them all the time, but they are only familiar with half of Power Apps, oblivious to the other face of Power Apps.
Model-Driven
What a shitty product name, or rather qualifier of a product name. Even when I try and explain it to customers, they are confused, because of what they think they already know. Microsoft really botched this one. I know that the plan was that these two completely different things would eventually converge, but giving them both the same name in the meantime was a huge mistake. Customers are thoroughly confused. It's not like Microsoft is afraid to change names, they do it unnecessarily all the time. As I am writing this, they are announcing a name change for "Office 365", a well-known and understood product, to "Microsoft 365", a name that was already in use for something completely different. For a really smart company, they can be quite stupid sometimes.
XrM in an Empty Pool
Model-Driven Power Apps are the XrM capabilities, in an empty pool. What I would give to go back in time to those customers who pulled the plug on D365. This was the product they actually needed at the time. But... it did not exist, so there's that... maybe I would have just suggested they wait a couple of years. What we have available today is an empty pool, with a low-to-pro code development platform sitting on top of it. We no longer have to waste time and money emptying the pool, or dodging big floats. Time to Value has been slashed. Development costs have been slashed. Time to ROI has been slashed. There's just a hell of a lot of slashing going on.
A Big Ask
If you are one of those customers, who went down the D365 path and wasted a lot of time and effort, only end up with nothing, I am aware that suggesting you to take a look at something else is a big ask. But, if you still have the problem, Microsoft may have caught up with your needs with Power Apps. Umm.. the other Power Apps.
