Changing a Field Type in Production Environment

6th March 2018

Author Siddharth Birari

So far in anyone’s experience in Salesforce development, one must have encountered the need to change the field type of a custom field for a given object. One foremost challenge that arises is the data loss in the process of changing the field type. Salesforce has provided a very wonderful and detailed document highlighting in what scenarios the data loss occurs and where it doesn’t.

This article is focussed on other challenges that occur while changing the field type, and an overview of how to overcome them.


What if…

Sandbox development is obvious and highly recommended. Carry out the field type exercise in a developer sandbox first and then deploy the field to a production environment. Wait. It won’t be so easy. You won’t be able to change the field type if:

  • It is referenced in your Apex code or any other custom code you’ve written.
  • It is being used in any other formula field, workflow rule, validation rule, workflow field update, process builder, lead assignment rule, case assignment rule etc. (and the list goes on).


Identify the references

There isn’t any standard out-of-the-box feature in Salesforce where you can identify what places a given field is being referenced. It’s important to know because one won’t be able to change the field type if it’s being referenced anywhere in the org; maybe in custom code or somewhere in the declarative model.

Though in an attempt to change the field type directly, Salesforce would prompt you about the field being referenced, but only about one reference at a time and not all of them. So more effort is involved to change the field type, and at the end of the day, it may become frustrating. After the frustrating task of successfully changing the field type, one might not recollect all the places where the field reference was commented out. IDE

The easy way to see all the places where the field is being referenced is to use the IDE. To achieve this, extract the metadata components in IDE and do a search on the field API name. This would enlist all the metadata components wherever the field is being referenced.


Change the Field Type

Now that all the components that include the field reference are identified, the field API name can be commented from the corresponding components, followed by changing the field type to the new one.

Once the field type is changed successfully, uncomment the field references from the components commented prior to changing the field type.



The field with newly changed type now needs to be deployed to the production instance. This exercise needs to be carried out in multiple steps again. One won’t be able to deploy the field straight away to production, since the field type now has changed and the same field with previous type is still being referenced in the components in the production environment. Phew... too much to do. This can be carried out in the following steps, assuming one is using change sets for deployment:

  • Carry out the deployment of components with field references commented out. This would allow you to deploy the field with changed field type.
  • Now that commented code is deployed to production, the field with changed field type can be deployed.
  • Undo the commented code. Carry out the deployment of all the components again with the field reference uncommented, returning the code to its original format.

There you go. Your production instance is now available with the field with its type changed.

Please note that this article has not factored in the activities which are required to address the data loss issues that can occur when changing field types.



Notes on Changing Custom Field Types