One of the dangers when working as part of a specific role within a technology-focused occupation is that a full 360-degree knowledge of an application, and some its more subtle nuances, can often be lacking. This is particularly true for those who work with Dynamics CRM/Dynamics 365 for Enterprise (CRM/D365E). For example, most people can say with confidence how an entity is created but may be less familiar with the process of removing an entity and the list of things you need to watch out for as part of this process. This can be exacerbated if your role is involved primarily with “build a solution” projects, where often you will build out components and hand it over to a customer; it is unlikely that, after this point, you will have much involvement on how the solution shapes, evolves and also (arguably) some of the challenges that can be faced when working with the application on a daily basis. This is, I would argue, essential experience and an area that should be addressed if you feel it is lacking in some way.

I encountered a strange issue recently when performing a tidy-up of an existing Dynamics CRM 2016 solution. The work involved “breaking up” the solution into more logical groupings, based on business functions. After getting these solution components archived into an unmanaged solution, we then proceeded to delete the components from the primary solution file, one by one.

Deleting solution components can often be a laborious process, thanks to the applications Dependent Components feature, which prevents you from deleting in-use components from the application. Whilst no doubt a highly beneficial feature to have in place, it can prove to be difficult to unwrap in practice. Assuming your team/business is following sound principals relating to change management, as I have argued for previously on the blog, all CRM Administrators/Customisers should have some experience of doing this. For those who have yet to take the plunge, though, it’s important to remember the following:

  • Dependent Components include pretty much everything that you can find with a Solution file, so you won’t need to look further afield in order to track down any components.
  • Relationships can be the trickiest component to remove dependencies for, as the Lookup field on the related entity will need to be removed from all forms and views first.
  • Certain components may need to be deactivated first before they can be safely deleted. For example, Workflows and Business Process Flows.

I definitely prefer CRM/D365E having this feature in place, but it can feel like a double-edged sword at times.

Going back to the task at hand, we were close to getting all the entities that needed deleting completed, but we encountered the following issue when deleting an entity:

The Component Type and Dependency Type fields were the only fields populated with information – Sdk Message Processing Step and Published respectively –  so we were initially left stumped at what the issue could be. We did some digging around within CRM to see what the problem is, by first of all querying Advanced Find to return all of the Sdk Message Processing Steps records for the entity concerned. There were two records that caught our attention:

Both records do not have a Name field populated, just like the Dependent Components highlighted above, and also contain the following useful Description value – Real-time Workflow execution task. This would immediately suggest that the issue relates to a Workflow of some description. But we had already deactivated/deleted all workflows that reference the Entity or its Attributes.

After some further research and a good night sleep, I came back to the issue and remembered some obscure information relating to Business Rules from MSDN and the how they are stored in CRM:

The following table describes relevant process trigger entity attributes.

SchemaName Type Description
ControlName String Name of the attribute that a change event is registered for. For other events this value is null.
ControlType Picklist Type of the control to which this trigger is bound.

The only valid value for this release is 1. This indicates that the control is an attribute. This value only applies when the ControlName is not null.

Event String There are three valid values to indicate the event:

  • load
  • change
  • save
FormId Lookup ID of the form associated with the business rule.

This value is null when the rule applies to all forms for the entity that supports business rules.

IsCustomizable ManagedProperty Information that specifies whether this component can be customized.

You cannot change process trigger records included in a managed solution when the IsCustomizable.Value is false.

PrimaryEntityTypeCode EntityName Logical name for the entity that the business rule is applied on.
ProcessId Lookup ID of the process.
ProcessTriggerId Uniqueidentifier ID of the process trigger record.

From the applications point of view, it appears that Business Rules are treated the same as the more typical Processes. This theory is backed up by the fact that Business Rules have to be explicitly Activated/Deactivated, just like a Workflow, Action or other types of process. After going back to the Entity to double-check, we confirmed that there were indeed two Active Business Rules configured; and, by deleting them and checking Dependent Components again, we were safely able to the delete the Entity.

When attempting to reproduce this issue within a test environment, later on, I was able to clarify that the issue does not occur all of the time. From the looks of it, both of the Entities that we were attempting to delete the above had a relationship and the Business Rules in question were directly referencing the Lookup field. So, when reproducing the issue with a standard Business Rule configured (i.e. not referencing any lookup field), I was able to delete the entity successfully. So it is good to know that it is a rare issue and one that will not be commonplace whenever you need to delete an entity. Nevertheless, this issue demonstrates clearly the importance of familiarising yourself regularly with scenarios with CRM/D365E that you are not generally exposed to, within a testing environment or similar. Doing this will almost certainly throw up a few things that you can learn at the end of it and better equip yourself for any problems you may face in the future.

Last week has been a particularly busy one for all things Microsoft concerned. Future Decoded 2016 came and went, with a whole range of interesting announcements and presentations from those within the industry. And, of course, we saw the release of Dynamics 365 for Enterprise on Tuesday, an event which I discussed more closely as part of last week’s blog post. There’s a lot about Dynamics 365 which is going to take some time to fully understand, and also a lot of features which are not yet fully available. I have been hearing rumours that there will be a December update, targeted at existing CRM Online users who wish to make the jump across, that will unwrap a couple of features that are currently disabled within Dynamics 365. Chief among these looks to be the App Builder and also what looks like some kind of sitemap editor tool! :O In the meantime, there a lot of changes that need digesting, and I wanted to focus this week on a particular group of new features/changes relating to Processes. For the uninitiated, processes is a broad term to describe a group of different Dynamics 365 for Enterprise (D365E) components that can be created within the system- namely, Workflows, Dialogs, Actions, Business Process Flows and Business Rules. Whilst not all of these have received attention as part of the new release, the ones that have definitely look to be in a much more enhanced and polished position compared to Dynamics CRM 2016 Update 1. Let’s take a look at some of these changes in more detail:

Process Designer

The introduction of the Process Designer for Business Rules, Business Process Flows and Task Flows is perhaps the most noticeable and welcome enhancement to processes. Now, instead of linearly attempting to visualise how your processes operate, you can very quickly grasp how they look via the visual designer. What’s more, you have the ability to drag and drop your components quickly and easily, re-ordering them accordingly and seeing clearly how each step flows into the other:


Out with the old…


…and in with the new!

What’s also welcoming about this is that, for those who prefer a more “old school” approach to seeing how a Business Rule is structured, the Text View window provides a means of accommodating this. A nice and welcome touch!

Business Rule Recommendations

I really like this next new feature 🙂 When it comes to data inputting, one of the major challenges you face is ensuring that the data is entered correctly. These problems can be compounded in situations where data needs to conform to specific rules – for example, if Field A and Field B equal ‘ABC’, then set Field C to ‘DEF’; otherwise, set to ‘GHI’. The common solution to this problem in the past is to look at programmatic means of ensuring data is entered correctly – generally via a Business Rule or a form-level JScript function. Whilst these generally are effective at addressing the problem, they could be prone to errors and can be seen as being too absolute a solution, that doesn’t address what could be an underlying problem within a business; namely, a lack of understanding of business processes and how things should be done.

The new Recommendation Action as part of Business Rules would appear to seek towards addressing this gap, by providing an unobtrusive way of alerting users that there is a problem with the data they have entered onto a form and giving them an opportunity to correct their mistake. In the process of doing this, you can provide contextual information that explains why the data needs to be changed – increasing transparency and understanding from end users of the application. Setting them up is very straight-forward – just setup your Condition and then you can drag and drop the new Recommendation component onto the designer screen. To see how this works in practice, let’s look at an example on the Contact form – we want to ensure that if the Spouse/Partner Name field contains a value, that the user is prompted to update the Marital Status field accordingly. First, we build our condition as we would normally in a Business Rule:


Next, we hook up our Recommendation component and configure it accordingly – setting the Recommendation properties and then our Set Field Value action

4 5

Your Business Rule should look like the below when ready:


When activated and then, upon navigation to the Contact form, we can see it in action; when the Spouse/Partner Name field is changed, a blue exclamation mark appears next to the Marital Status field. Once clicked, we get some guidance information and the ability to update the field:


Et voila! The introduction of this new feature is a welcome surprise on my part. One limitation currently is that only one type of Action is supported with a Recommendation – Set Field Value. Here’s hoping that this is expanded as part of a future version of D365E to include additional Actions.

Validation for Business Rules

Previously, when building a Business Rule, the only way you could effectively determine that there were logic problems in your Business Rules is by activating them and testing them yourself on the form level. This is a potentially torturous process that could very well result in errors seeping through unintentionally. Now, as part of the new visual designer, the logic can be validated at any point and is also validated upon save. If unsuccessful, you are alerted to this fact and given some guidance on what is wrong so you can look at fixing the issue:

8 9

Hopefully, having this built in now will help avoid some of the most obvious mistakes that can sometimes seep through when building a Business Rule.


Often, when you are attempting to document a system, you will want to include some kind of pictorial representation of the system – a process map, diagram or something similar. Now, with the updates made to Business Rules and Business Process Flows, you have the ability to obtain screenshot of the designer window – all through the click of the Snapshot button:




Pressing this will download a .png image of the Process, that you can very easily include as part of existing documentation relating to your system:


This is a very handy new feature that will no doubt save a lot of time in the future! One thing to remember is that, if you wish to include all Components underneath the Details section, then you will need to expand it first before pressing the Snapshot button.

Task Flows

Having come out of Preview from Dynamics CRM 2016 Update 1, Tasks Flows are still very much in their infancy and something which I am still trying to get my head around fully. My understanding is that they are essentially a combination of Workflows and Dialogs, but designed solely for the Dynamics CRM/365 for Tablets Mobile Application. From the mobile app, they are accessible from the new Summary area that appears when the app first launches (and where the heavily touted Relationship Assistant will reside once released). Taking the example After Meeting Task Flow, we can see how this looks in the mobile app. First, we launch the app and navigate to Summary area:


From there, we can see along the bottom of the tab all available Task Flows that can be launched based on the clipboard task list icon:

13Clicking this then launches a New Appointment record screen and then the first Page of the Task Flow which, once completed, will then execute the custom logic in the background:


Task Flows look very versatile and powerful, but I think will require some closer testing and experience before I’m able to comment further… :S

All in all, Processes seem to have received a lot of love and attention as part of the initial Dynamics 365 for Enterprise release. Microsoft has set the bar at the right level in creating the process designer, and the hope is that this is eventually rolled out for Workflows and other processes as well. Workflows, in particular, can benefit greatly from having a more visually accessible appearance, especially given the complexity that these can have when used to their fullest potential.

I was working within CRM recently, attempting to configure some form level logic in order to display/hide fields, based on certain conditions on the form itself. I went into it rather gung-ho and immediately started writing the following JScript function:

function hideFormFields() 


    var myField = Xrm.Page.getAttribute("jg_myfield").getValue();

    if (myField = "Value1") {



    else if (myField = "Value2") {



I then suddenly thought “Hang on – can’t this be done via a Business Rule instead?”. For CRM Administrators who do not have any previous development skills, Business Rules were a godsend when Dynamics CRM 2013 was first released, having been continually improved since. They essentially enable you to implement conditional logic and actions on your entity forms, without the need of writing a single line of code. Business Rules are, in fact, a form of JScript, utilising many of the capabilities available as part of the XRM framework. As an excellent case in point, we can very easily replicate the above code into a Business Rule, like so:


There is an important lesson here, that anyone who works extensively within CRM needs to always remember; if it can be done out of the box within CRM, then why would you go to the trouble and effort to write a JScript function? Here are some reasons why CRM Developers should always think twice before typing away on that new form-level JScript function:

Business Rules actually do a lot more than you’d expect

This is something I am guilty of forgetting, and I’m having to train myself to consider this more carefully in future. In the above example, I made the immediate assumption that showing/hiding form fields on a conditional basis was not possible via a Business Rule – how very wrong I was! This seems to underline a general theme with how CRM customisers/developers approach Business Rules, assuming a glass half-empty approach. As of 2016 Update 1, as well as being able to modify a fields visibility, Business Rules can also support the following scenarios:

  • Show Error Message
  • Set Field Value – Fields can be set to match the value of another field, a specific value (including lookups), the result of a formula (Date/Number fields only) or be cleared of data.
  • Set Business Requirement.
  • Set Default Value – Fields can be set to match the value of another fields, a specific value (including lookups) or as the result of a formula (Date/Number fields only).
  • Lock or unlock field

What emerges, when combined with the conditional logic builder, is a means of utilising some of the most frequently used methods available to you via the SDK. And we can also hope and anticipate that as part of future releases of CRM, this list will be expanded on further.

Business Rules are supported, whereas your JScript may not be

To summarise another way, although you can do lots of things via Jscript within CRM, that doesn’t mean that you should. One thing I have observed with those who work with CRM, but have had more of a developer background, is that there is tendency to utilise methods/code which is not officially supported by Microsoft within CRM. Looking around the CRM community, and you often see that an unsupported solution is provided to a specific requirement, but often with no warning label attached to stress what it is doing. A good example of something which is unsupported is manipulating the Document Model Object (DOM) of the current page. Just because it works now doesn’t mean it will in the future, potentially causing major problems for your CRM deployment. If you are ever in doubt, be sure to review the supported extensions article on MSDN for CRM, and always think twice before you start using that nice bit of code you find on a Google search.

Your JScript may cause problems for end users

So your JScript is supported – great! But that doesn’t necessarily mean it’s going to work well from an end users perspective. If your JScript code, for example, does not provide a sufficient level of error handling, your end users could end up receiving error messages frequently. Or perhaps consider a scenario where your code is handling your errors well and outputting them correctly for potential debugging; this can lead to more lines of code that are unnecessary, and cause an impact when running the application on certain machines/browsers. With Business Rules, you don’t have to worry about addressing that careful balancing act between form loading times versus JScript library sizes. And, you can be assured that the CRM application as a whole will be able to handle your custom logic without affecting the performance of your deployment.

Jscript should have a time, place and bespoke requirement

What I mean by this is that JScript should only really begin to factor in when you are dealing with very specific, business requirements that the application “as-is” has no means of satisfying. An example of this is if you need to provide specific data validation to a field (such as a telephone number or bank sort code number). The only way this is ever going to be possible is via some kind of Regular Expression (RegEx) validation, which can only be performed via JScript. As one the key takeaways from this blog post, I would stress that you should always first attempt to build a Business Rule that is designed to meet the requirement that you are looking for, utilising other out of the box elements where appropriate (fields, workflows etc.). When it starts to become pretty obvious that a Business Rule is not going to cut it, then you can “give yourself permission” to start writing a JScript function 🙂

A “No Code First” approach should always prevail

I was recently introduced to this simple concept, but it is one that got me thinking and re-evaluating many of my previous solutions that I have built within CRM and elsewhere. When attempting to provide a potential solution to a requirement within CRM, you should try and put forward two solutions (where possible): a solution that can be achieved using out of the box functionality and one that requires bespoke coding to resolve. It may be that the first solution requires considerable time to build within CRM, but doing it this way could mean your solution is a lot more readable and understandable for those going into the system in future. By comparison, your 3-6 lines of code could prove to be virtually indecipherable.

So, in conclusion, can you guess what your new “Rule” should be moving forward?

Going back to my earlier example of your CRM Developer, AKA Former Application Developer, person, you can anticipate that they will have a very good knowledge of what CRM is capable from an SDK point of view. What may be lacking is a good understanding and knowledge of application as a whole, and specific features (such as SLA’s, Business Process Flows etc.). I would invite these people, and in fact anyone who works extensively with CRM, to focus their learning efforts towards the functional side of the application, so that they can ensure they have a good grasp of what CRM is capable of doing with, potentially, just a few mouse clicks. And, finally, to always think twice and consider alternative solutions before deciding on the best option – for everyone involved.