What to consider in converting picklist to look-up relationships?

Question

A client currently has a number of Task Record Types that have picklists. The picklists are typically related to accounts of a given RecordType. In some cases, they're lists of child accounts that need to be updated on a regular basis as the number of children increases. They're also awkward to use, since they're getting too large for the UI (who wants to scroll through more than 6 or 8 options?).

The account manager has suggested they convert to look-ups and I've been asked to look at their code. I've searched the metadata and know which custom classes, pages, etc will be affected by the change, but have a sense that I'm may have overlooked something; that there's some standard page or related list that the metadata search tools won't recognize as being affected by this change. I've searched using the field names and labels which returned all the triggers, classes, custom visualforce pages, custom components, custom objects, standard objects, record types, reports, validation rules, approval processes and workflow that might be affected.

I'm considering running some dynamic apex to sort through all the objects for picklists that might contain the same names and/or labels. Beyond that, I'm not certain what more I can do to locate potential issues. What might I have missed that you'd suggest I look at independent of metadata?

Answer 1

I had to deal with a similar change recently. As you've done, I searched through all the metadata for references to this field, but I missed a Custom Setting reference, because it's not in the Metadata.

Since then, I always try and double check loosely coupled things like:

• Custom Settings
• Custom Labels
• Reference Tables (i.e. Custom Metadata before that became available)
• External applications, such as:
  • Conga Composer
  • ETL tools

I'm assuming you can use a full-copy sandbox to do some end-to-end testing on?

I found some code the other day that dynamically queried and set fields, but instead of using the field name, it generated the field name at runtime.

e.g. instead of a dynamic line such as myRecord.get('my_field_1__c') it had (simplified version):

nteger myNum;
String myField = 'my_field_' + myNum + '__c';
myRecord.get(myField)

This was within a for loop where the myNum variable kept increasing. I'd love to know how someone would find all references to my_field_1__c in this scenario :)

I guess the point is, without end-to-end regression testing, it's almost impossible to completely rule it out.