Changing field types
Storing data in different types of fields that Salesforce provides is a basic task. However, depending on the project and the deviations that cannot be foreseen at the beginning of the same, people may need to change some data types in order to adapt the fields, thus leading to a hopeless data loss without even knowing.
In this article, we will be showing which fields can and cannot be changed and which ones will or will not preserve data.
Which fields do not accept changes?
The following type of fields not only do not accept changes once created but other types of fields cannot be converted into these.
- Formula field.
- Roll-up summary field.
- Geolocation field.
- Text (Encrypted) field.
For starters, the first two types of fields cannot be changed to others because they are auto-calculated fields, which means that provided a series of functions and instructions Salesforce returns the actual value of the field and nobody can modify that result. Regarding geolocation, the reason why it cannot be changed is related to the organization limits related to fields. Geolocation is measured in 3 internal fields (one for latitude, one for longitude, and one for internal use) and the system does not allow changes in different quantities of internal fields. Having this feature in the field makes it impossible to change this type of field to another.
Last but not least, we have the text (Encrypted) field, which is a field that stores information that cannot be seen. It makes no sense to have the possibility to change it because this action would break its whole purpose.
Fields that only accept change in some conditions
The relationship fields lookup and master-detail can only be converted between them if certain conditions are met.
To begin with, in order to convert a lookup relationship field to a master-detail relationship field, the following conditions must be met:
- All the records of the object in which the master-detail will be changed must have the lookup field populated with a parent.
- The object that has the lookup relationship field does not already have two master-detail relationship fields.
Following the first statement, master-detail relationships can be converted to lookup relationships only if the parent object does not have any roll-up summary fields in it. If it has one it should be deleted and after that, all roll-up summaries deleted fields must be permanently deleted.
Text types and their conversions
The text-type fields are the most versatile in terms of converting fields because the great majority are compatible with them.
To begin with, the most basic text field is not only the one that can be converted to the most fields but the one that can accept most of them and not lose data. Text fields can be converted to:
Some notes to make to the changes listed above are:
- Auto number. The previous records will not be lost or modified and the new ones will auto number themselves.
- Email. The data will be saved but if someone tries to modify it an error message will pop up if the field does not follow the email naming convention. (example@heroforge.tech)
- Picklist/Multi-select. The string data will be converted to the first value of the picklists.
Carrying on, the text area field and text area (long) are similar to the basic text field but have some more limitations regarding the conversion of fields.
The conversion notes of the text area field are the same ones of the text field. However, the notes of the text area (long) are different from the previous one because this type of field allows more string characters. Converting a text area (long) field to a text or text area the string will truncate to 255 characters or the selected at the parameters of the field. Regarding the change to the text area (rich), this one will also be possible but a pop-up will appear recommending to test it before.
Thirdly, the text area (rich) can only be converted to text area (long), leading to a similar pop-up that the one presented above. This one will give the user two options: The first one will be keeping only the string element, and the second will be to save all the HTML.
The next three fields of this section are email, phone, and URL. These three can be converted freely between them without the risk of losing any data, but only by following the email naming convention notes mentioned previously. Moreover, the three of them can be changed to the previous text fields mentioned text, text area, and text area (long) also without the risk of losing data.
For the last field of the text part, we have auto number, which can only be changed to text, the same way that text can be converted to auto number. The resulting field will have the saved record of the auto number but it will not continue auto numbering.
Number-related fields and their conversions
We wanted to include currency, number, and percent in the same space in this article because they are perfectly compatible. Each one can be converted into the other two without risking any data. In addition, they can be converted into:
The notes to take into account here are reduced only to email, having the same restrictions as mentioned before. If anyone tries to change the record without changing the email field, Salesforce will force a usual email naming.
If the number fields are changed to any type of field that is not a number type, will change its base to a string element, and will not be possible to turn it back to a number field
Date-related fields and their conversions
Regarding the date types, date, date/time, and time are very limited in the conversions that are able to do – basically, are limited to one or none without losing any data.
Beginning with date, it cannot be changed to any other field without any data loss because of the way the date field is stored in Salesforce.
Following up with date/time, this field can only be changed to date, and if done so, the record data previously saved will trunk only to date losing the time value.
The last field in this section is time. It is not closely related to date and date/time therefore it cannot be changed to them without losing any data. On the contrary, it can be changed to the text field keeping the time structure. Lastly, this field can be changed to a number field and keep all the data, but the number of the time will be represented as milliseconds.
Multi-options fields and their conversion
For this last section, we have the three remaining fields checkbox, picklist, and picklist (multi-select).
Starting with checkboxes, they cannot be converted to any type of field without losing data, but they have a pretty curious feature regarding the default field. If the default field of the checkbox was unchecked the default field for the new field will be 0 and if it was checked it will be 1. This applies to any type of field excluding auto number.
On the one hand, we have picklist (multi-select), which cannot be changed to any type of field without risking data. Additionally, all data selected in the picklist will be lost and the options will only be saved if the conversion is to a picklist field.
On the other hand, the picklist field can change to picklist (multi-select) without the problem of losing data. Furthermore, if the picklist field is changed to a text field, the selected option of the picklist field will be converted to text.
Concluding, picklists can also be converted to checkbox resulting in only one checkbox field, the user can select one or more of the options that the picklist has and the current values will be transferred to the checkbox.
Summary
Wrapping it up, we have prepared two tables with all the conversions in a more compact way. The first one shows the fields that can be converted to others even though they may lose data. The second one shows all the fields, even the ones that cannot be converted.
Resources
No Comments
Sorry, the comment form is closed at this time.