<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=151938321911395&amp;ev=PageView&amp;noscript=1">

Resources

Posts by

Guest User

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.

Read More

Simplifying the Audit Process with FLODocs

The audit process can be a daunting task for any company. It is a complex process that requires precise and errorless documentation. Yet there are things that companies can do to simplify their audit process.
First, it is important to understand what are the main things auditors want to know:

Read More

Best Practices for Protecting Critical Reports in NetSuite

A common issue businesses face when using NetSuite is how to manage and track user changes to critical reports effectively. These ‘reports’ may be Saved Searches or Saved Reports that function as controls for or provide critical information to the business. If changes in these reports are not managed or tracked correctly, this can leave the business open to a large degree of risk and vulnerability for reliable reports. Potentially, even leading to bad business decisions made by management or inaccurate data reported to public markets.
Currently, NetSuite has two permission levels set up for changes, it does not matter which user role you choose, once the permission is set to “Report Customizations,” the permission level has four options:

Read More