As we began to settle into 2019, we finally saw a cohesive and logical strategy emerge concerning Microsoft Dynamics 365 Customer Engagement (formerly known as Dynamics CRM). The announcement of the Microsoft Power Platform helped in setting a positive direction of travel for the various so-called “business application” products - namely, the Common Data Service, PowerApps and Microsoft Flow. Customer Engagement still plays a central role as part of all this, as the in-effect underlying database of the entire platform. As part of this necessary re-alignment, we have seen several important and potentially disruptive announcements come out:

• Previously, customers would pay based on the total database storage consumed. This has now been segregated out into pricing for database, file and log capacity, which are metered separately.
• Licensing has seen further refinements, with new license types to address individual usage cases and a new, metered licensing for Portals, now rebranded as PowerApps Portals.
• The overall customisation experience for Customer Engagement is slowly but surely moving across into PowerApps. If you are not already using this new portal to manage your Customer Engagement deployments, then you need to start thinking about moving across today.

Potentially a lot to take in! This is why keeping abreast of what is happening is so important, either through following the latest community blogs or by attending some of the great events happening out there today. By doing this, you can see and hear about what is happening, often from Microsoft themselves.

Now, as August comes to a close, we see another important announcement relating to API request limits come out of the woodworks. If this is not correctly read and understood by ISV’s and developers, then I can imagine a whole heap of problems occurring. Let’s digest the salient points from the announcement to see just how big of an impact this will be:

The devil is in the detail

As is fairly typical of announcements like this, more questions are raised than answered. A couple from my side include:

• What is the pricing for the “add-on capacity” component mentioned? At the moment, this does not appear to be an available SKU on Office 365.
• Is there a set date on which the limit will be enforced?
• What tools (if any) do Microsoft recommend/advise organisations to use to monitor the number of API requests across different user accounts?

No doubt answers will be forthcoming, but the relatively short window relating to these changes could be tricky and cause organisations some problems.

Plug-in Operations are included

I’ve been having a lot of conversations regarding plug-ins recently and how, potentially, a complete re-think may be required in how they are architectured and deployed. This announcement would appear to throw this into tighter focus, as Microsoft are classing any plug-in message operation as an API call. This could, potentially, be the element that sucks up the most requests, particularly for any ISV solution or a highly customised Customer Engagement deployment. I’d also question just how this may work in practice as well, given that PSA, a Microsoft solution, utilises plug-ins across almost all aspects of the application. I would assume these to be subject to the same API request limits. In essence, plug-in developers will need to start analysing their code and introduce any efficiencies, where required. Alternatively, hiving all of this off to Azure via the Azure Service Bus could be the way forward, potentially.

Non-Licensed Users

Longstanding CRM developers will no doubt be familiar with the process of setting up a non-interactive user and the process this entails. These user types do not require a license, thereby allowing you to create dedicated service accounts to perform any programmatic operation straightforwardly. Microsoft limits you to up to seven of these account types, thus preventing any abuse. But other than that, there were no significant limitations with their usage. This is no longer the case as part of this announcement. Now, you will need to ensure these user types are assigned a relevant capacity add-on, that then dictates the number of requests they can process. Failing to do this will result in them receiving a grand total of zero available requests and, no-doubt, extensive errors in your particular application if utilised.

In principle, I am supportive of these changes, difficult though they may be to stomach…

Seriously, no joke here. Let’s consider an example, that bears in mind that everyone with a Customer Engagement instance is, in effect, sharing the same “space”. Why is it fair that an instance with zero API calls has to pay the same as one making thousands per hour and, consequently, causes performance issues for others? Also, is there a reason why this instance is making so many API calls in the first place? I think a clear subtext from this announcement is that a lot of people have, quite frankly, been taking the piss for far too long. Whether this be through poorly developed applications that do not adhere to best practice approaches, there are evidently a lot of API calls occurring against the backend platform. Many of these, I would warrant, are either excessive or completely unnecessary. While it is a shame that things have come to this juncture, I certainly see the logic in going down this approach. Sitting from Microsoft’s perspective, I, as a software provider, want to ensure that all of our customers are not impacted adversely by the actions of one organisation/individual. We should keep in mind also that API limits are already in place for Customer Engagement - previously set at 4000 requests, per organization instance, during a 5-minute sliding window. Ultimately, I think the writing has been on the wall for a while, meaning any anger should not necessarily derive from its surprise.

…but this is a hell of a short window for everyone to get their houses into order.

As much as I may agree with the direction of travel, that’s not to say I approve of how fast we are going. 🙂 Expecting ISV’s and end-users to get everything in place to ensure no disruption within 2 months is very optimistic. The amount of potential evaluation, refactoring, testing and pleading customer phone calls that may result from this is more akin to a six to twelve-month project. And this, of course, assumes ISV’s or developers are being proactive in communicating with customers or their businesses. I can fully anticipate a scenario of panicked frenzy in early October, as business systems start erroring and there is no-one immediately available to remedy the issue. Ultimately, a lot of this will come down to whether the API limits will be strictly enforced from October 1st onwards, or whether a “bedding in” period will exist. I sincerely hope Microsoft go for the latter.

Need some help in understanding how these changes impact you?

Attempting to digest and evaluate how these changes may directly impact your organisation could be tricky. If you need any help with this, feel free to reach out to me directly, and I’d be happy to discuss them further with you. You can also leave a comment below - I’d be interested in hearing others thoughts in regards to these changes.