There are many different times within a development cycle when you might realize that you need to deprecate or delete some of the custom fields you’ve created. Maybe you’ve built a prototype or two that didn’t meet your or the client’s expectations, so you ended up going in a different direction. Or perhaps you’re new to the org and you’re trying to clean up or do an audit of the system. Maybe the system/app has been updated to version 2.0 and 1.0 is being classified as “legacy.” These are all times when you need to consider whether deprecating fields or deleting them is your best choice.
After having a discussion with the team at Red Argyle on this topic, we’ve come up with some considerations for deleting versus deprecating fields. The flowchart above walks through the steps in determining which category the targeted field falls into. Here’s another way to think about your best course of action:
DO NOT DELETE if there is relevant data present in the field(s), as it will not be recoverable. Consider these alternatives:
- Deprecate field and keep information as legacy data.
- Copy data to field that will replace the deleted field.
DELETE if the data has been backed up or is not necessary. But remember–it is not recoverable. Also keep in mind that you will lose Field Tracking History if the field is deleted.
DEPRECATE if there is data present that you will need in the system for UI or auditing purposes. Deprecated fields can still be referenced in API, layouts, reports, etc. Data can also still be accessed.
Here at Red Argyle, we are constantly working on improving our QA process. Naming conventions, including those related to deprecated fields, are a big part of that discussion. We add the word “deprecated” to the help text and description of the field, but this doesn’t give us visibility on the object’s field list, so we also update the field label. It is very important that you DO NOT change the API name, because anything referencing the API name will break–Apex, Visualforce, workflows, formulas, etc.
Here’s where the naming conventions come in. We’ve reviewed and considered many different ideas on how to relabel the fields and determined the following standard to be the best for our company: the letter “z” in the beginning (to send the field to the bottom of the list), followed by the original field label, followed by “(DEP)” to visually represent that the field has been deprecated. Using this naming system universally keeps us organized and on the same page.
Here’s an example of that naming system in use: “zCustomFieldName(DEP)”
What are some of your considerations for deleting and deprecating fields? If you have naming conventions for this process, what do you prefer? Share your thoughts and tips with us below.
