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:

  1. View: The user can view reports, but not create or change them.
  2. Create: The user can create new reports, but not change existing reports.
  3. Edit: The user can create or edit reports, but not delete them.
  4. Full: The user can create, edit or delete any report on data they have access to.

It is generally the latter two levels, Edit and Full, that cause concern for SOX or ITGC Compliance customers. Their need to protect changes in some reports, when audited, requires approved customizations so reports are reliable and accurate. However, generally permission is not report-specific, but FLODocs can help in several ways by allowing specific reports to be subjected to more stringent change management controls.

What is FLODocs’ recommendation?

Although FLODocs can’t block edits, it can:

  1. Automatically warn about the risk of a change in sensitive reports,
  2. Automate approvals for critical report changes, and
  3. Automatically inform management if there is a change to a protected report.

A FLODocs best practice is to set up change control policies. These policies identify and protect critical reports and searches by requiring appropriate approval before any changes can be made. This can be done quickly, since it is a standard policy used by many FLODocs customers. Management can be alerted about any unauthorized changes to critical reports, with the changes stored in a change log to allow for roll back if needed.

The standard way to set this up is to:

  • Create a customized and tight policy that requires approval from at least the report owner and a higher level management user.
  • Associate the policy with the reports/searches either directly or by associating them with a process tied to the policy. 

Once policies are set up, FLODocs can flag any changes to the reports that were not approved as non-compliant. Now, having a broad team of NetSuite users is no longer a risk and critical reports are protected since no one can make unauthorized changes. If you would like to learn more about how to set up approval policies in NetSuite, contact us at