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

Branching Sales Process Flows in Microsoft Dynamics CRM 2015

Microsoft Dynamics CRM 2013 introduced us to the idea of Business Process and Process Flows but Microsoft Dynamics CRM 2015 takes this one step further by adding branching logic to the mix. Now it is possible to guide users through a particular process and enforce business rules across all devices.

Branching logic within entities can be implemented from a WYSIWYG editor and the branching logic is implemented in real time based on rules defined in the Process definition. An example of this type of process would be for selling services and products. A single process flow can be defined which, after a certain stage will split via conditional logic into other branches.

Set Up

Imagine we would like to create a branching process based on a value of timeline for an opportunity coupled with the value.

Processes are defined in almost exactly the same way as workflows which are familiar with. We start by defining a new definition.


Once the definition editor is open, we can start to build the structure of the process.


By clicking the ‘Add Branch’ icon, we can defined a field value that will trigger the branch process to happen.


Notice that the Value field can have OOP values or custom values, as shown by the first one in the list. This makes the process entirely flexible and complex logic can be created.

You can have as many clauses as you want with varying levels of complexity. You can use AND/OR clauses too as well as combinations but any fields in the conditional branch must be reflected in the parent stage. For instance, you cannot actually select Budget Amount as a field unless that same field is included in the Qualification stage Steps.


When the ‘Insert Stage’ icon is selected, the user can add a branched stage with additional steps, some or all of which may be required.


By continuing to add branches, stages and clauses, a complex business process can be built up.

Once you have your conditional branching logic, you can apply it to the opportunity and see it immediately available.


Processes can also be swapped using the ‘Switch Process’ menu option in the top navigation.


The inclusion of branchable logic in business process flows has definitely opened the field for flexible customisations and even better, these same process flows can also be controlled programmatically. Custom logic can collapse the control bar, skip stages and change the process being used based on more complex scenarios.

Marketing in Microsoft Dynamics CRM 2015

As the future moves ever onwards, so does software and with the much anticipated autumn launch of Microsoft Dynamics CRM 2015 we have been looking quite closely at the new features.

Integrated Email Editor

With previous versions of Microsoft Dynamics CRM, if you wanted rich and pretty emails for marketing purposes, you were confined to creating the HTML template outside and simply pasting the source into the editor. Within Microsoft Dynamics CRM 2015, there is a new rich text email editor that is suddenly a lot more useful to the marketing department.


Campaign Management Console

More intelligent lead scoring systems, multi-condition triggers, cross-campaign offers and finally – A/B testing! All this to make sure your marketing is better targeted and delivers better results. And our favourite? Webinar integration – for an even deeper insight into what works and which leads are passionate about your products!


B2B Marketing

Deeper lead management capabilities with webinar integration and improved lead scoring, including the ability to introduce multiple lead scoring models.


Sales Collaboration

Strengthen your marketing and sales synergies with the new Sales Collaboration Panel which allows sellers to provide input into campaigns and targeting. Sellers can gain visibility into the campaign activities and can control communications targeting their customers as well as setup and receive alerts based on their interactions.


Marketing Resource Management

Marketing plans and click to call via Lync get our hearts going. Combine this with the Yammer integration and marketing is very much a beneficiary of the new functionality.


So, there are plenty of new things slated for Dynamics CRM 2015 that will appeal to the Marketing department. In depth blog posts and actual walkthroughs to follow very soon.

Aggregate Calculations in Microsoft Dynamics CRM 2015

Following on from the Hierarchy View in Microsoft Dynamics CRM 2015, another nifty new component that is turning heads in the CRM world is the Aggregate/Rollup field functionality. Prior to 2015, if you wanted to do a calculation on a field or rollup some business information, you had to write code to do it and this limitation could end up being quite expensive for what amounted to a pretty simple requirement. In truth, it is very common for a Sales Team to want to know the aggregate cost amount for opportunity products right there on the Opportunity and there was previously no easy way to achieve this. Microsoft have included new functionality that makes this really quite simple to implement directly within the User Interface.

As part of the standard field definition that we are all familiar with, power users will notice a new attribute called Field Type. This is a drop down with some values dependent on the Data Type of the field being specified. As we know, Data Types can be one of the following :

  1. Single Line of Text
  2. Option Set
  3. Two Options
  4. Image
  5. Whole Number
  6. Floating Point Number
  7. Decimal Number
  8. Currency
  9. Multiple Lines of Text
  10. Date and Time
  11. Lookup

The Field Type drop down changes values dependent on the Data Type chosen above. Depending on that, the values will be either Simple (pre 2015 standard type field), Calculated (new for 2015) or Rollup (new for 2015).


As with all field definitions, once the field is created, these values are fixed and cannot be changed later. You cannot, for instance, change a calculated field back into a simple type field at a later date, although you can obviously edit the calculation ‘definition’ going forwards. It is necessary therefore to make sure that all fields have their correct purpose defined right from the very beginning of design time which does add some small overhead to the entire project.

Calculated Fields

Calculated fields can be used for almost any data type except Text, Image or Lookup fields. Calculations are performed synchronously on any field in the Form when the Save event is invoked.

Calculations are not necessarily arithmetical in nature and there are some useful built in functions though such as :


For the purposes of this demonstration, lets suppose that Orders can have a special discount applied based on the total amount of the order. We will need two new fields in the entity, one to record the special discount value and one to show the calculated discount. In the definition of the Special Discount Value (the field that will invoke the calculation) we set the Field Type to Calculated and select the EDIT button to create the definition for the calculation. Note that the Special Discount field will be a Simple type field since it is merely required to hold the initial value.


When the Calculated Field editor is opened, there is a standard IF….THEN…ELSE set up within which values can be selected. In the case of our scenario, if the Total Amount has value, then the Special Discount Value will equal Total Amount minus Special Discount. As you can see, the calculation is specified in English to help with understanding the logic.


The Action selection also usefully has a type of intellisense which helps you to correctly select the fields as necessary.


It is entirely possible to have quite complicated calculations and in this way, percentages, weighting and calculated dates are potential scenarios that can be addressed easily. Multiple conditions are supported as well as an ELSE and ELSE IF clause.


Once you have your definition specified, all that is left is to view the Form and invoke the calculation via the Save event. In this case, a £5 special discount was applied and the Special Discount Value now shows Total Amount minus the Special Discount.


Calculated fields can be used like any other field and lend themselves to being included in Views (for instance). In this case, My Orders view shows us that two special discounts were applied to these orders. Both fields can be sorted as shown with the ‘up arrow’ symbol.


Rollup Fields

Let’s suppose that the Sales Team would like to know the aggregate value of all Opportunity Products amounts associated with an Opportunity and that this value should be displayed in a field on the Opportunity Form. As we have observed, previously, this would have required a plugin or workflow to manage this information, but now, it can be achieved with just a few clicks from within the UI.

Rollup fields are designed to provide aggregate information from child records and so, we can use this Field Type as a definition for the Rollup field we are going to create. As with Calculated fields there is a limitation to the Data Types that are supported for rollup since you could not sensibly rollup a Text field for instance. In this case, only Whole Number, Decimal, Currency and DateTime fields are supported and only for certain operations as can be seen below.



In our scenario above, we can see that Currency and Sum are supported which is exactly what we would like to do.

First of all, we need to create the destination field for the rollup value that will sit on the Opportunity Form. We do that in exactly the same way as normal with the slight deviation that we choose the Rollup field type from the Field Type drop down.


Once we have that definition, we can choose the EDIT button and start to define the actual information that will be used. The source is the Opportunity since the field rests on the Opportunity entity and Use Hierarchy is No. These values are completely filled in by CRM. If there is no Hierarchy already set up for the entity, then the field will stay as NO and you cannot edit it. If you have created a hierarchy for the entity, then the field can be edited using the relationship definition created as part of that process. If Hierarchy is used, then the rollup will use the values of fields within that hierarchy as well and this can also be optionally filtered.


In our scenario, the related entity will be the Opportunity Product and the Aggregation will be SUM the Opportunity Product Amount field.


Usefully, there is a filter which is optional, so for instance, you might want to limit the rule to only SUM opportunity products which have a quantity greater than 1 or perhaps the CreatedOn is later than a certain date. This definition can be changed later if the user wishes to add another filter or different criteria but the field cannot be changed from a rollup type.


Once the definition has been created, all that remains is to place the field on the form and open the record.


Rollup Fields : Considerations

Unlike Calculated fields, rollups are asynchronous in nature which means that the actual calculation is updated every hour as part of the Asynchronous Jobs. There is the ability to manually invoke the calculation by clicking on the ‘recalculate’ icon in the field of the form though. The API also allows for the developer to invoke a recalculation as necessary. Rollup fields are also stored in the database just like any traditional field and so would be available to charts, reports, security and views. For instance, if we wanted to extend the My Open Opportunity View, we could add this field to that and see it in the Grid like any other field.


Interestingly, it is perfectly feasible for Rollup fields to be part of Calculated fields and vice versa. Some complicated business logic can be satisfied with very little effort on the part of the user. For instance, if we wanted to know the total value of discounts applied to orders (see calculated fields) associated with an account, we could create a rollup field with this definition.


If we added the field to the account entity and manually invoked the update :



As with all new functionality, there are some limitations to be considered.

In the general sense, workflows are not triggered by field updates unfortunately and this is certainly an enhancement we would like to see. To add to the general complications, latest values of calculated fields area are not available in the plugin pipeline. This could cause some consternation if you are trying to invoke a plugin based on a value in one of those calculated fields, but realistically speaking, if you want anything more complicated than the UI provides for, you would use custom development in the first place and generate the same calculation there. Obviously, development still has a role to play in CRM 2015 and wont be changing any time soon.

Calculated fields specifically are subject to the following limitations :

  1. Can only go one level up in an N:1 relationship
  2. Can only have all ANDs or all ORS in conditional logic.
  3. Not available for offline
  4. Calculations only refresh OnSave of the Form

Rollup fields are subject to the following :

  1. Only available using a single directly related 1:N related entity (Opportunity and Opportunity Products for instance)
  2. Rollup using another rollup field is not supported.
  3. Rollups are asynchronous and so the latest value will not always be available if changes are made to child records.

How take advantage of Hierarchy Views in Microsoft Dynamics CRM 2015

A perennial problem with relationship databases is how to actually visualise the links between the records and information. With Microsoft Dynamics CRM 2015 (Vega), Microsoft has implemented a completely new way to look at records and their relationships to records of the same entity. Microsoft has called this new visualisation component Hierarchy Visualizations and in my view gives the user an unprecedented insight into how the data relates to itself and other pieces of information available.

First of all, lets look at how to set it up and then we will discuss the implications of what is being displayed to the user.

Setting Up

In the same way that certain system entities are enabled for Bing Maps in Dynamics CRM 2013, Microsoft have chosen to do exactly the same thing for Hierarchy Visualizations in Dynamics CRM 2015 for entities like Accounts and Users. These entities have the Hierarchy component already enabled and this cannot be switched off. To be fair, it does make sense since you are most likely to require a hierarchical view of account and users, however, the component must be explicitly enabled for custom entities.

It should also be noted that Dynamics CRM 2015 only allows you to set up one hierarchy visualisation per entity and the Parent and Related entities must be of the same type.

Imagine we want to view a hierarchy for Cases. First of all, the settings can be maintained in the 1:N relationship. If you attempt to create more than one Hierarchy, then any others that were previously set will be unset automatically. Remember, you can only have one per entity.


Cases also has a Hierarchy Settings section where the actual implementation magic happens.


The purpose of the Hierarchy Setting record is to define which 1:N relationship to use (the one you just created above) and which Quick View Form to use for the tiles that will appear in the visualisation frame. You can use either OOTB Quick View forms or you can usefully create a brand new one specifically for this purpose containing information pertinent to what you are trying to do.

It should be noted that there are some slight limitations here.

  1. The hierarchy view tile will only utilise the first 4 fields in the View, so unfortunately, not very rich.
  2. You can only have one hierarchy setting per entity although the interface does appear to imply that you can have more.
  3. Hierarchy Settings are stored within the solution and therefore can be exported or imported across organisations. Obviously, this has implications for existing hierarchy views developed in other systems.

Step one is to create the Setting and if you don’t have a Quick View already to go, you can create one directly from the input form.


As you have created the relationship and the Quick View above, you can navigate to the Grid for the entity and there will be a new icon to identify that there is a hierarchical relationship between the entities.


This will work with any view, either the built in system views or a custom created view. In this example, I have created a view called Related Cases which will isolate any case that has a hierarchical relationship. Regular users of Advanced Find will note that there are a few new system attributes on hierarchy enabled entities which can be used for this purpose.


Further to this, there are a couple of additional attributes in the Advanced Find which can also help to isolate relational information. For instance, if we wanted our Advanced Find query to only show child cases for a parent case, we can use the new UNDER operator. There is a reciprocal operator of NOT UNDER.



The user can now click on the Hierarchy icon and a new window will pop open showing a graphical representation of the Grid data above. The user can navigate back to the case via the tile. Sadly, the case hierarchy appears to only allow 2 levels of depth, so there is no ability to keep adding child cases to child cases forever but this appears to be more to do with Cases themselves than the actual hierarchy mechanism. Accounts for instance allow as many layers as you like. Hierarchy information can also be reached via the actual entity and appears as an additional option in the ribbon as well as a quick button at the top right of the form.



Just to prove that Hierarchy is not limited to the two apparent levels of Cases, here is a hierarchy of Accounts.


By clicking on a tile, a number of options become available. For instance, the user can assign the case, email a link, follow, un-follow, start a dialog or run a workflow from this frame.

Each tile is fully URL enabled and so clicking on the Customer for instance will pop open the correct Account record. Further to that, this entire mechanism is also available in the mobile client and so a Sales Person could potentially view this sort of hierarchical view on their tablet.

There is also a new Hierarchy Security settings page where you can limit the types of hierarchy available and to which entities.


There are limitations to this new component, not least of which is the fact that there is no ability (at this time) to visualise links between different entities (Accounts and Competitors anyone?) and nor does it really show much more than you would be able to visualise yourself, but it is a definite start. I would like to see the same implementation on Connections for instance which would potentially prove more interesting from a business point of view. At this time there is also no mechanism to add the hierarchy view to a dashboard which would so be quite helpful and unfortunately, even adding a grid to a dashboard does not overcome the problem since the hierarchy icon is omitted from the list.

Using Sharepoint as an alternative to CRM for Mail Merge


We recently had a requirement where we wanted to automatically create Word documents which had pieces of information from Microsoft Dynamics CRM and were stored in a Sharepoint destination. MailMerge functionality has changed in Microsoft Dynamics CRM 2013 and it was looking like it would be a challenge to implement, but in the end, turned out to be quite simple using the power of Sharepoint rather than CRM to do the heavy lifting.

In this post we are going to explore a different mechanism for handling MailMerge.

Sharepoint Set Up

First of all, you will need to prepare your Document in Sharepoint to be used as a template. This should be a DOCX type and it should have ‘tags’ to denote where Sharepoint (rather than CRM Mail Merge) will place the relevant information just like a normal mailmerge. The template itself does not have to be in Sharepoint, it could be a filesystem directory for instance.


You will also need to prepare the Sharepoint metadata for the Document. To do this, you would navigate to the Document Library Settings area and add Columns as necessary.



Once you have added your metadata columns to the Sharepoint Library, every document stored in that library will have the accompanying metadata attributes available for completion. The illustration below shows the result of a completed merge.


As long as there is a column reference in the Sharepoint metadata and the same tag name in the template document, then Sharepoint will handle the mailmerge for you. It should be noted that a user can also navigate to the actual document in Sharepoint and simply Edit the document properties directly as well. In the scenario above, the DeveloperName is left blank and will be completed by the user directly within Sharepoint at a later point in the process.

CRM Set Up

I wont pretend that this step is plug and play, but if you have a Developer handy, it is very easy to arrange. The final step to the process is to create a custom workflow/process step which will aggregate the information that is required from CRM and then squirt the finished document into Sharepoint. Since the process of actually implementing a Custom Workflow Step is fairly well known, I will concentrate instead on the actual nuts and bolts. Assuming that you have the information you require from CRM all ready, the object is to put the document into Sharepoint and let Sharepoint do it’s thing.

In this, the secret is not so much in the actual document or in doing anything to it, but more to do with the values being passed along with the document.

1. Add a WebReference to your project pointing to the Sharepoint URL. It will usually take the form of http://yourserver/_vti_bin/Copy.asmx

2. Create the Copy Service


1. Now, to actually tell Sharepoint which values to merge, you will need to create a series of FieldInformation objects. One for each of the attributes you wish to ‘mailmerge’. Note that the DisplayName parameter must match exactly the name value in Sharepoint that has been assigned.


The AccountName attribute is derived from CRM directly and will be sent to the Sharepoint document when it is posted.

1. Squirt all of your FieldInformation parameters into a FieldInformation array


5. Now, send the Document to Sharepoint using the CopyIntoItems method being sure to add the fieldInfoArray information you prepared above.


The Final Result

Once you have registered the workflow step and added it to an onDemand workflow, you can use this technique anywhere. Some additional ideas might be to extend the WorkflowStep so that it is more generic or perhaps uses dynamic attributes. You can store the document template in Sharepoint itself and retrieve it for use. In our implementation, the requirement was for a unique document name derived by using a Base36 encoded sequential number, all of which can be achieved inside the workflow.

When the user opens the newly created Document from Sharepoint, the mailmerge has completed using the metadata you passed in the fileInformation array and the CopyIntoItems method.


The final step would be to hook that workflow up to a button and using JavaScript, invoke the workflow for the record selected in the Grid.

function ExecuteWorkflow(entityId,workflowLocalName) {

var workflowId = getWork

    alert("Executing workflow");

var url = Xrm.Page.context.getServerUrl();

var OrgServicePath = "/XRMServices/2011/Organization.svc/web";

    url = url + OrgServicePath;

var request;

    request = "<s:Envelope xmlns:s=\"\">" +

"<s:Body>" +

"<Execute xmlns=\"\" xmlns:i=\"\">" +

"<request i:type=\"b:ExecuteWorkflowRequest\" xmlns:a=\"\" xmlns:b=\"\">" +

"<a:Parameters xmlns:c=\"\">" +

"<a:KeyValuePairOfstringanyType>" +

"<c:key>EntityId</c:key>" +

"<c:value i:type=\"d:guid\" xmlns:d=\"\">" + entityId + "</c:value>" +

"</a:KeyValuePairOfstringanyType>" +

"<a:KeyValuePairOfstringanyType>" +

"<c:key>WorkflowId</c:key>" +

"<c:value i:type=\"d:guid\" xmlns:d=\"\">" + workflowId + "</c:value>" +

"</a:KeyValuePairOfstringanyType>" +

"</a:Parameters>" +

"<a:RequestId i:nil=\"true\" />" +

"<a:RequestName>ExecuteWorkflow</a:RequestName>" +

"</request>" +

"</Execute>" +

"</s:Body>" +


var req = new XMLHttpRequest();"POST", url, true)

// Responses will return XML. It isn’t possible to return JSON.

    req.setRequestHeader("Accept", "application/xml, text/xml, */*");

    req.setRequestHeader("Content-Type", "text/xml; charset=utf-8");

    req.setRequestHeader("SOAPAction", "");

    req.onreadystatechange = function () { assignResponse(req); };



function getWorkflowId(workflowName) {

var odataSelect = Xrm.Page.context.getServerUrl() + ‘/XRMServices/2011/OrganizationData.svc/WorkflowSet?$select=WorkflowId&$filter=StateCode/Value eq 1 and ParentWorkflowId/Id eq null and Name eq \” + workflowName + ‘\”;

var xmlHttp = new XMLHttpRequest();"GET", odataSelect, false);


if (xmlHttp.status == 200) {

var result = xmlHttp.responseText;

var xmlDoc = new ActiveXObject("Microsoft.XMLDOM");

        xmlDoc.async = false;


return xmlDoc.getElementsByTagName("d:WorkflowId")[0].childNodes[0].nodeValue;



function assignResponse(req) {

if (req.readyState == 4) {

if (req.status == 200) {

            alert("Workflow successfully executed");




As you can see, although mail merge from a user point of view in CRM is now less useful, there are other ways and means to achieve largely the same result. There are of course limitations to this approach, chief of which is that a CRM developer is required to implement the custom workflow step in the first place, but this need not be much of an impediment.

The future of Microsoft Dynamics CRM is web integration

The term “portal” can mean different things to different people, but generally a portal is a window onto business information that is generally only available to the internal business or a limited number of external users.

Within a portal, we might want to serve up information but also allow and empower users to interact with the business in a much more integral way. For instance, other than updating a name and email address, a company might want to allow visitors to administer their own account information, register their interest in a seminar, buy merchandise or request a sales call. All of these things can be handled by the administration/customer service/customer support team(s) using Microsoft Dynamics CRM, but it’s more efficient to enable your customers to make direct changes themselves to the data in CRM.

Traditionally building front end portals to serve up data from such things as Dynamics CRM, were costly enterprises requiring thousands of hours of development.  Although these days any twelve year old can knock up a website, integration with a back office system has always provided more of a challenge.  Over a year ago, Microsoft released a limited portal solution with some nice built in connectivity to Dynamics CRM, but it still required developer involvement to finish it off. Since then some CRM providers have taken this slightly further and enhanced the original offering.

Technology Management have formed a strategic partnership with one such pioneer, called ADX. ADX Portals are designed to be almost plug and play with basic functionality that you would expect like customer login, account administration, helpdesk administration. Further to that, the portal, being a website in reality, is still very much extensible and flexible when it comes to fulfilling the customers’ needs. Solutions are imported into the target Microsoft Dynamics CRM organisation using an installer which makes the management of components particularly easy. 

Brave new world

Using this latest technology, rather than a customer portal taking several months to design and develop, an ADX type portal can be deployed to a customer within a day!  Of course, it is unlikely that the portal will be a 100% fit out of the box and therefore some custom development may be necessary, but all the basic functionality would be available.

A basic ADX Portal comes in several flavours which are pre-configured to be a rough fit to typical types of business that might want to use it. There are five in all, Community, Retail, Partner, Conference and Company. All of these types have components which can be mixed and matched to suit the particular business. Features include the following:

  • Web Content Management
  • Service Scheduling
  • Customer and Account Management
  • Opportunity Distribution Management
  • Helpdesk (more on this in a moment)
  • Blogs
  • Polls
  • Ideas
  • Issues
  • Events
  • Knowledge Base
  • eCommerce with preconfigured PayPal and Authorize.Net gateways.
  • News and Announcements

Content Management

One of the most interesting aspects of these portals is the Web Content Management functionality of ADX which allows a suitably empowered member of staff to actively manage the portal contents and copy. Administrators can easily add new pages, change information, change navigation and move webpages around without the requirement for traditional web development skills such as HTML.

The actual website code itself still resides in IIS as you would expect, but it is the way that the pages and information is manipulated in Dynamics CRM that gives the website the look and feel. References to the webpages are created and stored in Microsoft Dynamics CRM and since the website runs on CSS3 and HTML5, the entire look and feel can be changed quite easily and quickly from within Dynamics CRM

Any authenticated Dynamics CRM user can write content and have it displayed in the portal with the click of a button. Since forms displayed on the website are derived from actual forms in Dynamics CRM, if it was decided that an additional field was required on the portal, then a System Customiser need only add that same attribute to the form in Dynamics CRM to have it automatically appear on the portal. The portal code respects Dynamics CRM restrictions when it renders the form, so a field which is “business required” in Dynamics CRM will also be on the website

Portal Features

A good example of a use for an ADX Portal is a helpdesk, a screenshot of the maintenance is shown below:


A helpdesk portal is available to use in ADX which allows visitors to notify, update, and administer cases logged with the back office team. Cases are handled as actual Dynamics CRM cases and so the back-office team will be able to view information and proactively work with the customer to solve the issue on a much more synergistic basis. There is an integration with the Knowledge Base which allows visitors to search for answers to common question and could double as a FAQ section.

Other components of interest are the Forums and Blogs integration. Blogs are well known to drive traffic to a main site and so act as a powerful marketing tool in their own right. Again, as with the website content management, blog posts are managed directly within Dynamics CRM. 

Upgrading Fears

The portal offering is both Dynamics CRM 2011 and CRM 2013 compliant. All solutions will behave correctly when they are upgraded from 2011 to 2013 so there is plenty of scope for forward compatibility. Likewise, the solutions will behave equally well on premise or as part of a Microsoft Dynamics CRM Online solution. The portal code is also device agnostic which means that a portal will work on any device and any browser. Visitors can log a call to the Helpdesk using their Android, Apple or Microsoft mobile device while sitting on a train travelling to a business meeting.


Businesses are born and thrive in an increasingly connected world where many people do much of their daily business via electronic media and a portal can serve as not only a shop front, but a method of direct communication with potential customers. In return, those customers will feel more in control of their interaction with you and it becomes more of a strategic alliance than the traditional view of a customer and a vendor. A portal is not only a relatively cheap method of marketing but also easy to implement and administer in the longer term. Portals are here to stay and the scope of the interaction with a customer is only limited by the bounds of your imagination.

And for customers’ of Technology Management, watch out for an announcement regarding our own use of Dynamics CRM and ADX Portal – a customer support portal for logging, tracking and updating Dynamics NAV, Dynamics CRM and Technical support issues.