A week is a small space of time in the Dynamics 365 Customer Engagement world at the moment, as we ramp up to the October release and the many changes this brings to the table. This week, some interesting developments occurred concerning CSP licensing for the product.
It seems to be non-stop changes and announcements when it comes to licensing for Dynamics 365 Customer Engagement at the moment. Now, as we move into September, we get yet another, which informs us of some potentially troublesome API limits, that will take effect from October onwards.
When starting with Power Bi Desktop in conjunction with Dynamics 365 Customer Engagement, you are presented with several routes to bring your data into the application. In this week’s blog post, I take a detailed look at four of these avenues, outlining the benefits of each one.
Project Service Automation provides a cornucopia of desirable functionality for organisations wishing to integrate their sales and project management processes tightly. Be careful, though when implementing this app when using custom calculations within Dynamics 365 Customer Engagement, as you may encounter a few issues…
Longstanding Dynamics 365 Customer Engagement professionals will be well versed in the capability to auto-create new entities and fields, based on a data import file. This functionality has been exposed fully within the Common Data Service as well, which naturally means the same kind of issues can crop up.
Having the ability to straightforwardly obtain a records Globally Unique Identifier after programmatically creating it within Dynamics 365 Customer Engagement can help significantly with data integration requirements. This is a relatively easy task when working with the Web API using JScript but less so if C# is your language of choice...
Sink Limitations with the Dynamics 365 Customer Engagement/Common Data Service Connector for Azure Data Factory
The Dynamics 365 Customer Engagement/Common Data Service connector for Azure Data Factory can, in most cases, fit into your data integration needs. However, it is worth highlighting the two field types which are, specifically, not supported; namely, the Customer and Owner field types.
By default, the Dynamics 365 Customer Engagement connector for Azure Data Factory V2 exposes a predefined list of fields, that must have data mapped to them for any Copy Data task to complete successfully. This behaviour can be impractical depending on your particular scenario; fortunately, there is a way in which you can override this.
Feature deprecations can often cause some degree of disruption, especially if they involve custom code. Microsoft has recently deprecated the Xrm.Page object for JScript form functions in Dynamics 365 Customer Engagement. Find out more about this change and what you will need to do to fix this as part of this week's blog post.
Azure Data Factory V2 not just has 1, but three separate connectors that all claim to hook up to Dynamics 365 Customer Engagement/Dynamics CRM! So which connector is the "right" one to use and what differences do they have? With a little help from Alan Partridge, we can clear up any confusion...