How to Safely Change Standard Field Lists

When demonstrating FLODocs, we often show a situation in which someone wants to change a custom list to add or remove some values. Every day, you can be sure, someone, somewhere fries critical pieces of their NetSuite account by changing list values.

Today, I could have been one of those people, making changes blindly or relying on tribal knowledge. Instead, I used FLODocs to identify the risks and ensure that I corrected them. I am going to explain the change I wanted made and what steps I took to alleviate risks of the change.

The Scenario

Until now, FLODocs was only available for NetSuite. We had created customer categories in our account for different types of NetSuite customers (Public, Private, Non-Profit) to assist our marketing efforts. Now that FLODocs change management is available for Salesforce (SFDC and other Force.com applications), I needed to either add similar categories for Salesforce or make the categories independent.

However, many customers run both SFDC and NetSuite, so the right choice was to revise the categories to remove the word NetSuite.

“But if I change it, what will break?”

Looking for Trouble

Our account has thousands of customizations. The first step was to locate any relevant objects that could be affected using FLODocs. FLODocs doesn’t automatically create customization records for standard fields like ‘category,’ but instead, a search can be performed on the impact on these fields using ‘Field String’ on the FLO Customization record.

What I needed to look for was:

• Any script or workflow that uses the Category field.
• Any search that uses the Category field in a formula or a filter.

I created a quick Customization Search by:

1. Going to the FLODocs tab.
2. Selecting Customizations.
3. Choosing Search.
4. Going to Advanced Search where ‘Field String’ contains ‘Category.’

I added the following fields to the results:

• Name
• Type
• Date Last Used
• Search Formulas
• Search Filters
• Type (Grouped)
• Internal ID(Count)
• Clean-Up Status
• Change Request
• Create Change Request
• Field String (for reference at the end since it can get long)
• Employees Using Customization

It was a good thing I checked, since there were 185 objects I needed to think about:

• 141 Searches
• 34 Entry Forms
• 9 Transaction Forms
• 1 User Event Script

Analyzing the Results

(a) The Forms

I was not worried about the entry and transaction forms because:

1. Category is a standard field on Entity forms.
2. Changing the list won’t impact the form.
3. The Transaction forms are referring to a different category field that has the same script ID.

(b) The Script

The first big concern was the User Event Script. I clicked on the User Event Script row to drill down to the list of scripts and identified the script. While clicking through, I immediately noticed that the Date Last Used field showed that the script had not been used since mid-2015. I checked the Deployments tab on the FLO Customization record and noticed that there were no deployments. We no longer use this script so there was nothing to worry about, but before I left, I flagged the script to be cleaned up.

Opening the Improvement Tab, I set the Clean-Up Status to “To Be Cleaned Up” and the Clean-Up Comments to say they were no longer deployed and some information about what I believe it was used for based on the script metadata. This can now get caught on our regular clean-up reviews. Alternatively, I could have created a change request to clean it up right away.

(c) The Searches

So how did I clear 141 searches? My change needed to remove the word NetSuite from each category so I only focused on searches that both:

• Used the Category field and
• Had the word NetSuite in a Search Formula or Search Criteria.

I changed my search to add these criteria and reduced the list to 19 searches.

Sorting through these by Date Last Used, I identified searches that had not been used this year. I flagged the unused searches to be cleaned up reducing the number to 16.

Checking the Employees Using Customization field, I scanned for any searches that are only used by one person which may enable them to be cleaned up rather than be changed. I recognized two searches that I created, but no longer use, and flagged them for clean-up.

Next, I scanned each search checking the formulas and filters to identify potential risks. In the end, there was one search that was used in our commissions process that needed to be adjusted. If we had not fixed it, our commissions would have been incorrect. I attached that specific search to a new change request called “Remove NetSuite from Category” in the “Create Change Request” field. This instantly created the Change Request and attached the search to it. The change request was routed for approval and passed on to a developer.

The whole process of narrowing thousands of potential objects to just the one we needed to change took less than 5 minutes.