by: Robin Schaareman

In this article I would like to share some of my experience and best practices about deleting components in an unmanaged/managed environment. First you will read about the characteristics of both unmanaged and managed solutions, then a best practice to delete components and in the end a conclusion.

Characteristics

On several websites/articles you can find a lot of information about managed and unmanaged solutions. The most important characteristics are shown here:

Unmanaged solution

  • Flexible – you can add or remove components
  • Used in DEV environments – unmanaged solutions can be exported as managed
  • Deleting an unmanaged solution won't remove all components in the environment. They will be available still (including the data)

Managed solution

  • Can't add or remove components directly
  • For ISV's a good way to implement solutions on environments
  • Deleting the managed solution will remove all components from the environment including the data attached to it

Obsolete components

Once you work with a so called DTAP (Development – Test – Acceptance – Production) street once in a while it happens that some of the components in the solution become obsolete. How to remove these properly? To make this work there are some tips and tricks to smoothen this process:

1.Remove all the dependencies of the component in the DEV environment
It is highly recommended to remove all of the dependencies of the component you want to get removed. If any of the dependencies are becoming obsolete as well, make sure to follow these steps for that component too. There are scenario's where you remove a component in DEV and struggle to remove it in any other environment due to the dependencies of the component. If you want to remove a field, make sure to make it non searchable.

2. Check data/usage
If the component you want to remove is a field, make sure to check if that field has been used in the past couple of weeks. Sometimes fields or other components are being used in processes that are needed for other functionalities for example. Also make sure there is no data in production that needs to be preserved. Once a component is deleted the data which can be stored on it will be removed as well.

3.Rename the component
If you are working in a team it is useful to rename a component that becomes obsolete. This way everyone within the team knows that this component has no dependencies or data on it anymore and the usage of the component has been double checked. To easily find components that are obsolete put ZZ_OBSOLETE before the components name. The ZZ make sure it will be visible on the bottom of any list so you can easily delete it in other environments instead of searching for it.

4.Deploy above changes to all the environments this component is in
If the component is in Production already then it is recommended to deploy the above changes to T A and P before actually removing the component. This will minimize the problems you can encounter once you try to delete a component.

5. Deleting the component
There are several ways to delete components, but you need to start in your Development environment. After that you can use the holding solution + apply functionality during a deploy to clean any fields that are not in the solution anymore. If you are working with unmanaged solutions it is also possible to clean components directly on the environment itself (without a deploy).

Conclusion

There are several ways to achieve a deletion of a component in your solution, but as said before it is recommended that you discuss with your team what will be the policy on this. If you and your team have a clear understanding on what to do when deleting a component, you will minimize the number of problems/errors you can encounter.