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.
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:
- Going to the FLODocs tab.
- Selecting Customizations.
- Choosing Search.
- Going to Advanced Search where ‘Field String’ contains ‘Category.’
I added the following fields to the results:
- 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:
- Category is a standard field on Entity forms.
- Changing the list won’t impact the form.
- 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.