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.