Introduction

There are many resources out there that address how to construct NetSuite saved searches. Despite this, NetSuite users still make a number of mistakes frequently when building their saved searches. In this blog post, we are going to explore some of the more common mistakes made by NetSuite Administrators and Developers as they configure saved searches to support business requirements.

While some of these mistakes may seem obvious, it is still critically important to get these right. As you review each mistake, let it be a reminder that it is important to get the basics right for system configurations and migrations before jumping into more complex areas of NetSuite reporting.

‍

‍

Mistake 1 - Forgetting date/period criteria

This mistake comes into play when building transaction saved searches. When creating your saved search criteria, it is easy to overlook date and/or period criteria when you have very specific criteria in mind. For example, let’s assume you are creating a saved search for transactions for a specific customer and you transact with that customer in a non-functional currency. In this scenario, NetSuite will convert the “Amount” field to the consolidated functional currency equivalent values. The exchange rates that NetSuite uses is driven by saved search settings.

‍

‍

Pay particular attention to the wording for the “Current” bullet point. Specifically “If none is selected, uses the rate for the data/period when the search or custom KPI is run.”  In other words, if you do not set the appropriate date range or period, you should expect NetSuite to convert transactions to functional currency using the exchange rates for the period in which the report is run and not the period of the transactions themselves.

This can result in the reporting of incorrect “Amount” values when delivering the results of your saved search to the intended recipient. If in doubt, add date/period criteria to your transaction saved searches.

‍

Mistake 2 - Forgetting to apply standard criteria

For any NetSuite saved search you need to keep in mind some of the standard criteria to apply. What do I mean by “standard” criteria? Really any criteria you would commonly expect to see for that particular saved search type as well as those applicable to most saved search types.

Consider a transaction saved search. For the vast majority of use cases, you will be looking to report on transactions that have been posted to the general ledger. As such, standard criteria you should expect to see on this saved search type would include “Posting = True” and “Memorized = False”. Having these standard criteria in place will ensure your saved search results agree back to your general ledger. You will typically want to narrow down your transaction saved search to a specific subset of transaction type(s), so don’t forget to add that criteria unless you truly want to see all transaction types in your saved search results.

‍

‍

There are other standard criteria to consider. “Inactive = False” will be common to most entity-related record types in NetSuite. For customer records specifically you likely need to clarify the “Status” of the customers you wish to include in your saved search results, with “Customer-Closed Won” being commonly used.

‍

Mistake 3 - Ignoring the security settings

As important as it is to get your saved search criteria right, it is even more important that you have the correct security settings in place. NetSuite saved searches do not have a “security settings” tab, but they do have configuration settings that restrict the ability to modify criteria and even view saved search results.

The first field to consider is “Public”. Checking this box makes the saved search available to all users with sufficient permissions. Users can both run the search and view the results, but does not allow them to edit the saved search configuration.

‍

‍

The great thing about this particular field help is that it confirms all of the key security settings for the saved search. Do be careful when checking the “Run Unrestricted” check box on the results tab, as this will allow users to access the saved search results for records they would not normally have access to based solely upon their user role permissions. This field is typically paired well with the “Disallow Drill Down” field. The example NetSuite provides is as follows:

“For example, an unrestricted search with summary-level results listing sales reps’ revenue totals could disallow drill down, to prevent viewers from seeing transaction-level data that includes sensitive commission amounts.”

So take the time to review your saved search security settings before you just check the “Public” check box and move on.

‍

‍

Mistake 4 - Trying to work with very large data volumes

A common complaint of NetSuite saved searches is that they take too long to load or simply time out. In other words, system performance can be a challenge. The answer is typically to schedule the saved search results or persist the saved search results, so they can execute in the background. That is certainly one approach that allows users to work with larger data sets, if they are willing to wait.

An alternative approach is to take the time to limit the data volume to only that which you require. In some cases this may require the creation of multiple saved searches, with slightly different criteria in order to break up the data set into small chunks. Consider whether your saved search criteria is restrictive enough - will you have to filter on the results? If so, think about how to modify the criteria to avoid the need to do this. Also think about whether you need each and every column in your saved search results. Can some of the columns be derived from others? Do you really need “Internal ID”, “External ID” and “Name” fields for the same record?

Ultimately, it is worth taking the time to review your saved search criteria and results to see how you can further limit the dataset to exactly what you need to report on. This will support the execution of saved searches more efficiently and, in theory, reduce any noise around them taking too long to execute.

‍

Mistake 5 - Thinking you need to summarize data outside NetSuite

Most NetSuite users are still accustomed to working in Excel. One of the reasons, in my opinion, is because those users believe they just need to extract the raw data from NetSuite, so they can manipulate it in Excel. In reality, this “manipulation” can be performed inside the system. NetSuite allows you to summarize, highlight and filter your data, among other things.

We are going to focus on the use of, or lack of, summary types as an alternative to extracting data to Excel and pivoting.

NetSuite offers several grouping functions or “Summary Types” to users when creating saved searches, which are pretty self explanatory. In the following mistake we will explore a more specific use case where these groupings are critical to get the required data outputs.

Salto Tip: Don’t forget that when working with summarized saved searches, they do not function well with the “Reminders” dashboard portlet. For summarized saved searches, the reminder will display 0 results, even if the summarized results contain >0 rows of data.

‍

‍

Mistake 6 - Not leveraging system note fields

When you are looking to get more insights as to how particular NetSuite records have been created and modified in the system, you should leverage system note fields. System note fields track the creation and modification of NetSuite records, including the user that took the particular action, the context in which it was performed e.g. UI vs CSV Import, the old and new value of a field that was modified, as well as the date/time each of these events occurred.

There is sometimes reluctance to use the system note fields in NetSuite saved searches, because without the appropriate grouping, users will see many rows for a single record in the saved search results. To avoid this, users will need to take advantage of the “Summary Type” options we saw in Mistake #5 above.

Let’s consider a specific example to show how valuable the system note fields can be when summarized appropriately. Example:

I have been asked to obtain a list of all sales orders that have had the total updated to zero in the current fiscal year.

Criteria:

‍

‍

Results:

‍

‍

With the right criteria and results (summarized), I can provide accurate saved search results to whoever made the request. Without the above “Summary Type” values set, I receive multiple saved search results for the same sales order. With the “Summary Type” values I now receive a single result for each sales order modified.

‍

Mistake 7 - Not considering alternatives to saved searches

Have you ever started to build a saved search and struggled to find a particular field? We have all been there. Users will be quick to add a formula field to the saved search results that references the internal ID of that particular field. In some cases, the results will now display the values you were looking for, in others you will receive an “ERROR: Field Not Found” response. In these cases it is quite possible the field you are trying to access is not available to NetSuite saved searches. In which case, you need to consider alternate solutions.

One such solution to consider is Suite Analytics Datasets and Workbooks. If fields are not accessible to saved searches, you should first see if the field is accessible to Datasets. If it is (and in many cases it will be) then recreate the saved search as a Dataset and use that going forward.

A good example of this is the “Account” record type in NetSuite. Certain fields are not available when creating an Account saved search, but are available when creating an Account Dataset. If you are looking to confirm which accounts in your chart of accounts are subject to revaluation or elimination on consolidation, you will need to create an Account Dataset, as the related fields are not available to saved searches. There are many other examples where Datasets and Workbooks exceed the capabilities of more traditional NetSuite saved searches.

Try it for yourself and see which fields were previously inaccessible and now accessible via Suite Analytics reporting functions.

‍

Mistake 8 - Still migrating saved searches manually

The migration of NetSuite saved searches between environments can be a time-consuming and error-prone task, posing a common challenge for NetSuite Administrators. NetSuite provides various out-of-the-box solutions, such as Copy to Account, SuiteBundler and SuiteCloud Development Framework (SDF), to support migration, each with its own strengths and limitations. While SDF may appeal to those more technically inclined (NetSuite Developers), some users prefer user-friendly alternatives like SuiteBundler and Copy to Account for executing NetSuite saved search migrations. Users must diligently address any environment dependencies before completing the migration to avoid the risk of introducing duplicate configurations (typically custom fields) into their Production environment.

An alternative automation solution for consideration is Salto, a SuiteApp that empowers NetSuite Administrators and Developers by enabling faster deployment of custom developments. Salto excels in comparing environments, identifying discrepancies, confirming record dependencies, and facilitating easy version rollbacks.

So stop wasting time on highly manual migration efforts and leverage some of the great tools available to you, so you can focus your time on more value-add initiatives for your business.

‍

Best Practices for working with NetSuite Saved Searches

1. Always reference date/period criteria when running NetSuite transaction saved searches. If no date/period criteria is set, NetSuite will apply consolidated exchange rates to “Amount” fields based upon rates in the current period, not the period of the transaction. This can lead to incorrect search results.
2. Apply standard logic to your NetSuite transaction saved searches, such as “Posting = True”, “Memorized = False”. This will ensure your saved search results agree back to your general ledger, which only include transactions actually posted.
3. Prior to publishing a saved search, double check the security configuration to make sure that only the intended users can interact with the results. Key settings can be found under the “Results” tab and “Audience” tab.
4. Limit the volume of the data you are trying to display, by setting appropriate criteria and keeping results columns to the data points you need to report on - remove superfluous columns. This will support executing saved searches more efficiently.
5. Keep your saved searches simple. Where possible, avoid large quantities of custom formulas. Not only will this improve performance, but will allow for better support and maintenance of those saved searches when formula criteria may change in the future. Custom formulas can be powerful, so use them, but only when necessary.
6. Agree upon consistent naming conventions to allow users to quickly find the saved searches they need. If you allow users to create their own saved searches, the volume can stack up very quickly, making it more challenging to find the required saved search.
7. Leverage summary types to group data, making the results more concise and typically more informative. Just don’t forget that if you are leveraging saved searches for dashboard reminders, summary data will display 0 results in the reminder dashboard, even if the summarized results contain rows of data.
8. System note fields are a great way to get more insights into how records are created and modified, but without the appropriate configuration will result in many results returned for the same record. When you need those granular details, make use of system note fields and summarize the results (group/max/min) to avoid having many results for each record.
9. In some cases it would be best to leverage Suite Analytics Datasets and Workbooks vs a saved search. If certain fields are not accessible in saved searches, you should attempt to recreate  the saved search as a Dataset. There is a good change the field(s) you need to include in your results will be available in the Dataset configuration.
10. Stop migrating manually - Migrating NetSuite saved searches from one environment to another can be challenging, especially when attempting to do so manually. In addition, doing this manually is risky due to the number of settings on any given saved search. Consider leveraging a tool, such as Salto, that will manage the migration process of your saved searches, including dependencies, seamlessly.

For more information on these best practices, check out Salto’s blog posts that explore some of the things that NetSuite Developers and NetSuite Administrators should consider when working within the NetSuite ecosystem. By following these best practices, you can manage your NetSuite saved searches efficiently and effectively.

‍

Final thoughts

NetSuite saved searches are an essential part of any NetSuite user’s toolkit. The ability to quickly reference a set of data from the system, with criteria as simple or as complex as desired, makes them indispensable.

Make sure to stay on top of the number of saved searches in your NetSuite environment. The number will balloon over time without the required oversight to purge saved searches no longer required. Working with a large number of saved searches requires a standard naming convention to allow users to easily find what they are looking for.

All that said, saved searches built incorrectly can lead to frustrated end users if the results take too long to render, or the results do not match expectations, resulting in additional reconciliation efforts. Lean on the above best practices next time you build a NetSuite saved search - you might find yourself simplifying criteria, reducing columns or even shifting over the Suite Analytics datasets to access fields not available in saved searches.