Microsoft Dynamics CRM 2015 SDK – What’s new

With the all the buzz around the imminent release of Microsoft Dynamics CRM 2015, being a developer, I thought I would take a look at the new CRM 2015 SDK that has been released. You can download it here.

First of all, this is a pre-release version which means that things (as always) could change without warning. In practice, this is generally unlikely and most functionality will stay the same, but you should be aware of it anyway.

I have all the versions of the SDK going back years and so it was very interesting to compare even the 2013 version to the 2015. Happily, the changes in code style seem to be far less dramatic than CRM 4 to 2011 for instance and seem more like an iterative update rather than a complete rethink. I really had to look closely at the two SDKs to find the differences, but there are some and they look very useful.

From a personal point of view, I think this is a good thing because it means that we are building on a base of continuous knowledge rather than having to take a left turn into the unknown and solve all the old problems all over again. What is noticeable is that the Form Scripting aspects have been extended to take account of all the lovely new toys Microsoft will give us in the new release and that is to be expected.

Some long time enhancement requests have finally been realised :

  1. Field Level security for system entities (hurray)
  2. Improved advanced finds.


Many other blogs in the web have already published a high level list of SDK changes, but it is worth repeating them.

  1. Product catalogue enhancements (the idea of product families and cross sell, up sell)
  2. Hierarchy data
  3. Application of hierarchy security models which adds yet another dimension of security. The jury is still out on the usefulness of this however since multiple layers of security can lead to a tangled web indeed.
  4. Use of calculated and rollup attributes created in CRM (discussed here)
  5. Form scripts that now interact with business process flows and other form script additions (Access header controls and something new called PreSearch)
  6. Field level security with system entities
  7. Custom help content although I have never seen help utilised all that much
  8. Creating of business rules rather than writing code
  9. Use of two factor authentication
  10. New messages in the Organisation web service
  11. New messages in the Deployment web service
  12. New entities
  13. New privileges
  14. New NuGet packages (if you are not yet using NuGet, you really should look into it).

Lets take a look at them in order.

Product Catalogue enhancements

Clearly, there has been a lot of work around the product catalogue and it has come a long way since 2011. Once again, Microsoft are using the word ‘hierarchy’ in conjunction with something and the product catalogue can now be organised in a hierarchical structure by creating bundles under a product family which defines related products and added properties of the parent product family so that child products automatically inherit that information. Unfortunately, defining product properties is not programmatically supported and so will have to be implemented directly from within the CRM UI. Interestingly, the SDK also says that product properties cannot affect the pricing of a product, this implies that the Dynamics CRM pricing engine does not support changing the price of a product based on a change in the product property values.

  • Group products into bundles or kits
    1. Bundle : is a collection of products that are related and can be sold independently
    2. Kits : a collection of products that comprise one unit (note, kits are now deprecated)


  • Discount whole bundles
  • Create related products
  • Define substitutes, cross sell and up sell
    • ProductSubstitute.SalesRelationshipType can be one of the following : 0 = up-sell, 1 = cross-sell, 2 = accessory, 3 = substitute.
  • Custom pricing instead of CRM pricing.
  • Localised values for certain product properties
  • No limits to the nesting levels for the product families – you can have multiple layers for added granularity
  • New CloneProductRequest message which allows the cloning of a product family, product or bundle record and create a copy of the record under the same parent node. Cloning also copies the properties of a product

If we take a look at an opportunity that contains opportunity products where a product hierarchy has been defined, the user is presented with the following.


As you can see, all the Suggestions are in one place and grouped into either Cross Sell, Accessory, Up Sell or Substitute, any of which can be added by the user directly at that point.

System settings also exposes some useful values to set such as the maximum number of products in a bundle.


With all that said, here are some useful examples demonstrating what can be achieved in the Product Catalogue using the SDK.

Sample: Create and publish products

Sample: Clone product records

Sample: Add products to a bundle

Hierarchy Data

Hierarchy is the new way to think of many things within CRM 2015 and not surprisingly, there is much information in the SDK around it. We have already looked at Hierarchy Views in entities but the SDK also talks about entity relationships and how to edit them. Each entity can have just one self-referential one-to-many entity relationship that is considered hierarchical. This declaration is included in the metadata of the relationship. There is a new OneToManyRelationshipMetadata class which has a new IsHierarchical property that specifies whether the entity relationship should be considered to be hierarchical. There is also a new EntityMetadata.CanChangeHierarchicalRelationship managed property that can be used to control whether the hierarchical state of the entity relationships included in a managed solution can be changed.


A word of warning though, the following system entities have hierarchical relationships that cannot be changed : account, systemuser, product and position.

All of the settings can be configured using the customisation tools in the web application without writing code, but developers can also define hierarchies programmatically using metadata APIs or query the metadata to understand which entity relationships are considered hierarchical.

Query Hierarchical data

Developers can take advantage of the new query condition operators to query entities with explicit hierarchical relationships. These operators only apply for the entity relationship specifically defined as this type. The condition operators allow for queries that are above or under other records in the hierarchy.


Note, that because querying hierarchical data can be resource intensive, there is a default limit of 100 recursions allowed. However, this limit can be adjusted using the Windows Powershell commands through the deployment webservice. Depth settings also apply to hierarchy security and can be set via the Hierarchy Security interface under Settings.

Apply commands to hierarchy visualisations

New hierarch visualisations allow people to navigate through records and apply commands on selected records using the command bar. Custom commands for these visualisations support the same contextual information available to commands for views so it is possible to disable or enable commands based on the records currently selected and perform actions on that selected record.

Apply hierarchical security models

A new security model to allow people to view the hierarchy settings. This alone could potentially do away with the idea of programmatically having to share records. In addition to this, there is a new concept called Position Hierarchy. Administrators can define various job positions in the organisation and arrange them in the position hierarchy. You can add users to any given position or tag a user with a particular position. A user can be tagged only with one position in a given hierarchy; however, a position can be used for multiple users. Users at the higher positions have access to the data of the users at the lower positions, in the direct ancestor path.

In addition, there are two new privileges that support this new concept, privAssignPosition and prvWriteHierarchicalSecurityConfiguration.

As I mentioned above though, I am sceptical as to just how much this new security model will bring to the already crowded security table. Between standard role based security, field level security, business units etc, I really don’t see a need for additional security based on hierarchy as well. As with most things Microsoft though, there is often method in the madness and no doubt the advantages will make themselves clear when we are actually using the product in anger.

Calculated and Rollup Fields

To my mind, this is quite the most exciting development so far since much of the work in CRM is to do with calculating and rolling up fields. It is the most common requirement I come across and this will certainly make life a lot easier. I have already discussed Aggregate fields in another post but it is worth looking at it from the SDK point of view rather than the user perspective.

All attributes will now have a SourceType property that can contain the values in the following table.


In addition there are new properties associated which support calculations and rollups.

  • Formula Definition contains the XAML definition of the formula used to perform the calculation or rollup. The only supported way to change this value is through the application formula editor, but that doesn’t mean that it cannot be changed programmatically. More information on defining rollup fields and calculated fields can be found at the links.
  • SourceTypeMask is an enumeration defining whether it is calculated, rollup or invalid.

Interestingly, integer calculated attributes can be derived from a decimal or a currency attribute and it does look like many combinations are supported. Calculated attributes are available in the retrieve plugin pipeline and the post image of an entity record on update or create will contain the calculated values at stage 40.

Limitations of calculated fields

  • You cannot use values in a calculated attribute that reference a related entity, another calculated attribute or a logical value in the same entity to sort data returned by a query, although the query can specify that the results should be ordered using a calculated attribute, the sort direction will be ignored. If the calculated attribute references only simple values in the same record, sorting works normally.
  • Only attributes from an immediate parent entity can be used in calculations.
  • Saved queries, charts and visualisations can have a maximum of 10 unique calculated attributes
  • Calculated attributes can reference other calculated attributes in their formula but they cannot reference themselves.
  • Calculated attributes don’t have values when a user with CRM Outlook is offline.
  • MaxValue and MinValue metadata properties cannot be set on calculated attributes.

Rollup Fields

There is a brand new CalculateRollupFieldRequest/Response method. A note of warning though, these messages are synchronous while the general rollup is asynchronous which means that it is possible to find yourself working with out of date or inaccurate information since the related attributes involved will not be taken into account at that point.

Limitations of Rollup Fields

  • Rollup attributes cannot be used as a workflow event or wait condition. They don’t raise the event to trigger a workflow.
  • The ModifiedBy and ModifiedOn attributes for the entity are not updated when the rollup attribute is updated.
  • The maximum of 100 rollup attributes can be defined within an organisation. Each entity can have no more than 10 rollup attributes
  • A rollup attribute formula cannot reference another rollup attribute
  • A rollup attribute formula cannot reference complex calculated attributes. Only calculated attributes that reference simple attributes in the same records are supported.
  • A rollup attribute formula cannot include records in an N:N relationship, only 1:N
  • Rollup attribute formulas cannot use 1:N relationships with the ActivityPointer or ActivityParty entity.

Form Scripts and interacting with Business Process Flows

Another exciting development. Business process flows have been enhanced to support branches and conditions as discussed (here). The Xrm.Page has been extended to take account of this and to allow the developer access to all the functionality directly.


There are two new events for process flows, OnStageChange and OnStageSelectedEvent which can be used to trigger business logic when a stage is completed or moved. Unfortunately, neither of these events provide a user interface to register the event handlers, you must do this dynamically in the OnLoad event.

Here are a couple of examples of what can be achieved.



Access business process flow controls

Controls in the business process flow control follow the naming convention where "header_process_" is prepended to the name of the control. For example, if the ‘name’ attribute is in the header, you can access it.

var nameControlInBPF = Xrm.Page.getControl("header_process_name");

Accessing Header controls

Controls contained in the header can now be accessed using the convention "header_" to prepend the name of the control. For instance, if the ‘name’ attribute is in the header of the form, you can access it using this :

var nameControlInHeader = Xrm.Page.getControl("header_name");

Lookup control PreSearch event

The lookup control has a new PreSearch event that occurs just before the control launches a dialog to search for records. There is no UI to set events handlers for this event but you can use the addPreSearch and removePreSearch methods on the lookup control to add or remove event handlers for this event. You can use these events to change the results displayed in a lookup based on the form data current just before the lookup control shows search results for a user to choose from. This could be very handy if you have a calculated field for instance.

Field Level security for system entities

Definitely a long awaited addition. Previously, field level security could only be applied to custom entities but this has now been extended to a limited number of system entities too. The restrictions are in place simply because all system users need access to certain attributes and therefore, field level security would make no sense.

There are new metadata properties that can be queried to determine whether field level security can be applied.

  • CanBeSecuredForCreate
  • CanBeSecuredForRead
  • CanBeSecuredForUpdate

Additionally, you can detect which fields have been secured using the IsSecured property.

This does raise some interesting problems for developers however since we often require the Retrieve and RetrieveMultiple methods in plugin code. The field level security will respect the field level security of the calling user as you would expect and this could lead to null values being returned, so take care when considering the context of the plugin and who might be using it. Unfortunately, you cannot tell the difference between a null value returned by no data and one returned through insufficient privileges which is a bother. It would perhaps have been more useful if there had been an additional metadata attribute that showed this.

Adding custom help content

I am not a fan of custom help content, but there is new support for this often neglected aspect of development. Administrators can configure the system to override the default help content by specifying a URL to open instead. The page to open might be a static webpage or a Sharepoint document or indeed any URL addressable destination. Everything can be set from the System Settings and entity settings.

Use of two factor authentication

Typical authentication practices that require only a password to access IT resources may not provide the appropriate level of protection for information that is sensitive or vulnerable. Two-factor authentication is an authentication method that applies a stronger means of identifying the user. Typically, it will allow to to ask for another proof of identity :

  • Something known (such as a password or pin)
  • Something possessed (a smart card or authentication key)
  • Something unique about the users appearance or person (a fingerprint)

I’m struggling to see how this would be used to be honest since it seems to apply to Exchange Online mostly. Perhaps Microsoft envisage the idea in future of users accessing Microsoft Dynamics by means of a single fingerprint since fingerprint scanners are becoming more common on mobile devices.

New messages in the Organisation web service

We like lots of new messages and it was only to be expected with the new functionality.


New messages in the Deployment web service

Funnily enough, just the other day, I was talking to a colleague about the possibility of programmatical backups and such, so it seems Microsoft have anticipated this requirement.


New Entities

New entities can be found by querying the entity metadata IntroducedVersion property. Entities added to CRM 2015 have the value To view the entity metadata you can use the MetaData Browser solution included in the SDK

Some notable new additions

  • HierarchyRule
  • HierarchySecurityConfiguration
  • Position
  • RollupJob
  • RollupProperties


A very nice addition and something that is fast becoming indispensible in the developer world is NuGet (see and Microsoft have obviously embraced this whole heartedly. SDK assemblies and some command-line tools are now available direct from the package manager console within Visual Studio and this enables developers to keep their project up to date with the latest releases of the SDK assemblies and tools. The lovely aspect of Nuget is that packages in the projects and assembly references are automatically updated and taken care of for you. NuGet packages were available for CRM 2011 and have been widely used by this organisation in the past, but it is nice to see that this will undoubtedly be continued in the future. It is always a worry when adopting new practices that rely on third parties that they continue to be available into the future.

At this moment in time, only the CRM 2015 SDK core tools are available in NuGet, but if you search for CRM 2013, the full assembly packages are available.

clip_image004< /a>

So, there you have it, a not so quick walk through what is new for developers in Microsoft Dynamics CRM 2015. I am sure there is much more to discover buried in bowels of the SDK documentation.

Some notable tools that are in the SDK are :

  • Configuration Migration
  • Device Registration
  • Metadata Browser
  • Package Deployer
  • Plugin Registration
  • Web Resource Utility
  • PortalBase solution
  • Powershell commands

Leave a Reply