7

I have a custom field on the user object that I need to change from Field Type Text to Field Type Multi-Picklist.

The field is referenced more than 500 times in 25 Classes, Triggers and VisualForce Pages. To commit the change, I am about to fo the following:

  1. Comment all references of the field in classes, triggers and pages (sandbox)
  2. Change the field type
  3. Modify test classes to adjust to commented lines
  4. Deploy change to production environment
  5. Uncomment all reference to field in classes, triggers, and pages (sandbox)
  6. Revert changes done to test classes
  7. Deploy again to production

I am hoping there is a better way to do this. Any suggestions would be greatly appreciated.

3

These are always tough.. If it's that often referenced I often go for a new field instead of field type change. That way you will suffer less from references and dependencies between classes, as you don't have to do a 'big bang' scenario but have the option to move over gradually if things don't go that smoothly. It might seem relatively easy doing this on a sandbox, but wait until e.g. your test coverage drops because of the commented out fields..

Main drawback is that all list views, reports, etc need to be updated as well since it will be a different field. And you will need a (simple) data migration.

Also, did you check for references in the rest of the org, e.g. formula fields, validation rules, workflow rules & field updates?

To get the complete picture, I often do a download of the complete metadata to Eclipse (refresh the metadata and check all the checkboxes to get all the metadata) and use CTRL+H to search across the entire project. That will also give you references in workflow, formulas, list views, reports etc. It also gives you the option to search and replace and save directly to the org from which you fetched the data (e.g. production).

5
  • 1
    thanks for the answer, would you recommend creating a temporary field, changing all the code references to the temporary field in order to change the existing field type, and restoring the code references to the changed field afterward?
    – AlexandreJ
    Mar 24 '14 at 20:10
  • 3
    Hmm didn't think of that. Not at all a bad idea, as it will maintain your test coverage and replacing is a lot easier to do than commenting out. And you will work around the drawbacks I mentioned above. Might be the best of both worlds :-) Mar 24 '14 at 20:18
  • @AlexandreJ - I have done that many times with great success. The only area it would be tricky is in standard page layouts since it will append the new field to the end of the layout, not in the section where the field you're swapping. Jul 15 '15 at 15:52
  • 1
    I think that the new approach deserves an answer of it's own.
    – Saariko
    Jul 23 '15 at 8:40
  • @HungryBeagle correct, but once you restore the references, and delete the "mock/temp" field, it will be hidden back. This process should not take long.
    – Saariko
    Jul 23 '15 at 8:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.