Change control and management are important considerations for any IT system - and CRM is no different in this respect. Business processes are often subject to change at the drop of a hat, and organisations should ensure that they have robust, effective and, most of all, efficient processes in place for change management. Often these changes may preclude the removal of a particular aspect of a system - in CRM’s case, this could be a Form, a View or even an Entity field. You may often just decide to take the “easy” way out and not remove these components at all, choosing instead to hide or obscure them. Whilst this is fine in the immediate to short term, you are storing up problems long-term if you do not have a robust process in place to ensure these unnecessary or legacy components are eventually removed. The problem is, though, depending on your customisation deployment method - either as part of managed or unmanaged solution - your options in this regard could be hampered. It is, therefore, important to be aware of what the potential limitations are to both types of solutions so that you can structure your customisations in the most appropriate way. In this week’s blog post, we will take a closer look at some of the for and against arguments when it comes to removing solution components from your production CRM system, the behaviour of solution files and how they can assist and even impede a change management process.

So why should you ensure that unnecessary/legacy components are removed from your Production system? And is there a case to not remove them at all?

• Components can potentially take up unnecessary space within your solution, leading to delays in performing solution updates. If you also have entity fields in your CRM that are no longer in use but are still storing data, then this could have adverse effects on your database storage levels - an important and essential consideration for CRM Online deployments in particular.
• Clarity and simplicity are hallmarks of a well managed and maintained system. Being in a situation where you have components in your system, that could easily be interpreted as being still in use or active, could lead to hours, if not days, of confusion and wasted time.

Clearly, there are practical, if not somewhat idealistic, arguments in favour of the above. So what are the arguments against?

• Removing a component almost straightaway could present problems if, for example, it turns out that the reasons for its removal were mistaken. You would potentially create more work for yourself in having to re-create a particular customisation when keeping it could have saved considerable effort and time.
• The above can be compounded further if it turns out that crucial business information was stored in, for example, a field that is deleted. Keeping the field intact can ensure that these potential situations are avoided.

Let’s see now things look in practice when we attempt to emulate a change process within CRM

For testing purposes, we have created a custom entity - Test Solution Entity - which contains 2 custom Forms, Views and Fields:

This entity has been moved into an unmanaged solution, which will be exported as unmanaged and managed and then deployed into a separate CRM environment. We will then observe what happens when we push out an update to the solution, that has had certain components removed - in this case, the following components:

• Test Form 1
• Test View 1
• Test Date Field

Unmanaged

Updating an unmanaged solution will do nothing to existing components that have been deleted - even if you specifically delete them from the solution in your development system. Therefore, as a best practice, any component that you choose to specifically delete from your unmanaged solution will need to be noted down and included as part of your release notes for your solution update. Once the update has been completed, you will then need to go into your production system and proceed with removing these components. Regardless of the type of customisation, you should encounter no problems deleting them - in most cases, all required dependencies for the component will have been removed as part of your solution update and the components themselves will be in an unmanaged state, meaning you are unrestricted in what you can do with them.

Managed

You may assume that a Managed solution update would differ from an unmanaged in behaviour. In fact, for this example at least, when we import our updated managed solution, then the components we deleted are persisted in the solution. What’s worse, because these components are in a managed state, the steps involved in removing them may be complicated significantly. Fortunately, for Forms and Views, there is a Managed Property that can be configured to allow us to delete a Form/View if it is in a managed state:

These settings always default to True, so you do not need to specifically remember to set them.

There is some bad news, however - there is no such setting available for entity fields:

In addition, the following customisation components can not be set to Can be Deleted whilst in a managed state:

• Entity Relationships
• Business Rules
• Global Option Sets
• Web Resources
• Processes (Workflows, Dialogs etc.)
• Reports
• Connection Roles
• Templates (Article, Email etc.)
• Security Roles

This can present a problem over time if we assume that over the lifecycle of your solution, you need to remove redundant fields - these will be maintained and will only be removed if you choose to completely uninstall and re-install your solution. Depending on the nature of your solution, this could cause the following problems:

• Uninstalling the solution will delete all entity records from the system, as all components in the solution will be deleted.
• There could be significant time and effort involved in the re-installation process - most likely this will need to be done out of hours, given that everything within your solution will not be available for the duration of the re-install.
• If you have other unmanaged/managed solutions that have dependencies on components within your managed solution, then this could cause issues with these customisations; and could even mean that you have to re-install these solutions as well.

Conclusions or Wot I Think

The above examples have looked at situations purely where you are making bespoke customisations to CRM. Sometimes deleting components may not be possible at all, particularly if you are using “out of the box” (OOB) components included with CRM. In these cases, you have no choice but to obfuscate these parts of the CRM systems as part of the customisations you make to the system - either through a well-defined security structure or by simply not exposing such elements of the system via the sitemap, for example. Putting OOB components aside, if we are to look at purely bespoke customisation elements of a CRM deployment, I would argue that striking a balance between the two extremes - leaving components that are no longer required in your system compared with deleting them at the first available opportunity - is often the best way to proceed. For example, having an internal process in place that ensures removal requests are signed off by a senior member of the business or by having a “grace period”, where customisations are flagged for deletion but not actioned until a set amount of time has expired. Tied up as part of this, you can very straightforwardly perform backups of your CRM data via the Export to Excel feature. Given how easy and accessible this feature is, there really is no excuse not to perform backups of fields that you intend to delete; then, if the worse happens and you need to restore customisations at a later date (which, on a separate note, should be straightforward so long as you keeping regular backups of your CRM solution files!), you can very quickly restore the data within these fields.

No matter which approach you take, I would argue that it is ultimately preferable to ensure that your CRM solutions are kept in a tidy, current and clear state at all times. You are doing a huge disservice to your current and future colleagues within your business by not following this mantra. In the process as well, you take a rather cavalier approach to what I would hope would be(!) one of your businesses most important assets.