Introduction

The most commonly used NetSuite saved search is the transaction saved search. Transaction saved searches can provide real time information on business performance from a reporting standpoint, through related dashboards, reminders and email alerts. Let’s say you are asked to notify the Sales Director when an opportunity record exceeds a certain threshold and the probability changes to 70% or greater, you wouldn’t need to actively monitor the system or reach out to the opportunity owners to get this information. Instead, you can leverage out of the box saved search functionality to notify the Sales Director immediately.

This is one of an infinite number of possibilities with transaction saved searches. Given the applicability, it is critical that all NetSuite end users understand the data that they are reporting. It is all too easy to provide incorrect data that in turn drives incorrect business decisions.

Taking our previous example one step further, let’s say the Sales Director set a threshold of USD 100,000. If the saved search was created to reference the opportunity currency and not constructed correctly, the Sales Director could get notified of opportunities much less than USD 100,000. If the opportunity was 1,000,000 Korean Won (KRW) and the transaction saved search did not appropriately translate that to ~ USD 700, the Sales Director would get notified.

Salto Tip: Prior to sharing any transaction saved search make sure you have tested a sample population of data to validate the amounts shared in the results. Go back to source transactions to validate. It should only take a few minutes and will give you the confidence in the results you are sharing.

One wrong transaction saved search can erode trust in the process and reliance on NetSuite data, so let’s make sure to get them right first time.

Importance of getting your transaction saved searches right

As we just saw, it is very easy to present the incorrect information to your business if transaction saved searches they rely upon have not been built to meet requirements. Let’s explore some of the key considerations when building these transaction saved searches

Criteria

When you are building your transaction saved search you need to go through your “checklist” of standard criteria and apply the right values based upon the given requirements.

1. Date/period criteria - Set the appropriate date or period criteria for your search. If you don’t, NetSuite will apply current period consolidated exchange rates to your saved search results as opposed to the rates applied to the transaction period.
2. Posting - Set “Posting = True” to exclude any transactions that have not yet been approved in the general ledger.
3. Memorized - Similar to Posting, set “Memorized = False” to exclude any memorized transactions that have not been processed as approved transaction records.
4. Type - This multi-select field drives which transactions are displayed in the saved search. Limit the results to the requested type(s). This will also improve performance of generating the saved search results by limiting the volume of data.
5. Main Line - This determines whether you want to see transaction header data or line level data or both. Setting “Main Line = False” will result in line level data only. Note: this will exclude journal entry transactions as NetSuite considers all journal entry lines to be “main lines”. As such, it is generally recommended to exclude this criteria entirely unless you’re specifically looking for header level data on specific transactions, such as a sales order.
6. Tax Line - This criteria determines whether to display the tax data in the results. By setting “Main Line = False” and “Tax Line = False”, NetSuite will display all non tax lines on a given transaction e.g. customer invoice line level details, excluding tax.

Screenshot showing the standard criteria “checklist” to think through when creating a transaction saved search

Amounts

With any transaction saved search, pulling the correct “Amount” values is critical and it is not always straightforward with many different amount columns that can be referenced. In the Results tab of your saved search make sure you have set the “Consolidated Exchange Rate” field to “Per-Account” if you want the “Amount” to be displayed in the consolidated functional currency. This is generally the requirement, which is why NetSuite sets this value by default.

Amount and Amount (Foreign Currency) are most commonly used to get at the transaction level data and the impact at the consolidated business level. Sometimes businesses need to report on additional values as well, such as the functional currency of the reporting subsidiary (not consolidated level). This can be achieved, but not in conjunction with the consolidated value unless using a custom formula. Fortunately the formula is simple: {fxamount} * {exchange rate}

As we discussed earlier, validate a sample of the saved search results before relying upon the data to drive business decisions.

Screenshot showing how to establish a 3-column transaction saved search that displays the transaction currency, subsidiary currency and consolidated currency

Summarized Data

The ability to summarize data directly in NetSuite allows for actionable insights from the system without having to export to Excel and pivot the data. This lends itself to business process automation where reporting might have been handled manually in the past.

Perhaps you want to know for each customer how many sales orders they have had to date, as well as data on the amount (total, largest sale, smallest sale and average sale). This can all be achieved in a single transaction saved search.

Screenshot showing results columns that can be set to achieve the desired results by leveraging the “Summary Type” options available

Salto Tip: Don’t forget that summarized transaction saved search results do not display in the reminders portlet on your home dashboard. If you are using the reminders portlet to drive certain business processes make sure you are referencing non summarized search results, otherwise the value displayed will be zero, when the underlying data confirms otherwise.

NetSuite continues to innovate across all key areas of the platform. Let’s explore some of the latest enhancements to these features in 2024.

‍

New NetSuite Features

In the 2024.2 release, NetSuite made some updates to a few specific areas of saved search functionality.

Users now have the ability to use custom fields when using the price book saved search. Specifically, these custom fields are now available under the criteria, results, filters and price book dropdown menus. Users also have the ability to filter by price book in a subscription search.

In the 2025.1 release, Netsuite has announced a new HTML formulas in saved search feature. This enables users with the Administrator role to assign the “Create HTML Formulas in Search” user role permission to other users. This change improves the security of saved searches and raises awareness of the risks of inserting HTML and scripts into a saved search. Find more details here.

Here are links to the latest NetSuite Release Notes for quick reference.

• 2025.1 NetSuite Release Notes

• 2024.2 NetSuite Release Notes
• 2024.1 NetSuite Release Notes

Challenges with Managing Customization Manually

Managing transaction saved searches between different NetSuite environments can be difficult, especially when attempting to recreate them manually in your Production environment.

Transaction saved searches have many different features and settings. If just one criteria, formula or field is different in some way it can have a significant impact on the saved search results. When creating a more complex saved search that includes conditional logic in the criteria tab, the consequence of inadvertently setting “AND” instead of “OR” and vice versa can have a huge impact on the results. If this is missed and your business starts to rely on the results to manage their business processes this could impact your customers, vendors, partners, employees and more depending upon the scenario. With the smallest difference having the potential to make a huge impact, the inherent risk in migrating your transaction saved searches manually is just too HIGH.

Another scenario to consider is when a transaction saved search is part of a larger NetSuite customization that involves scripts or workflows. With the interdependency between these customizations, the migration process can be challenging for even the best NetSuite Administrators when asked to complete this process manually. This can be a point of frustration for the NetSuite Admin Team, because the migration process itself does not add a lot of value, but can take a very long time in the event that they run into dependency issues between the two NetSuite environments (source and target - generally the Sandbox and Production environments.

Combining those two scenarios, if a transaction saved search is part of a scheduled script solution and the list of transaction records in the saved search far exceeds expectations, you could find yourself scrambling to modify search criteria at the last second to manually halt a script deployment that is executing on transactions that it shouldn’t be executing on. This is why it is incredibly important to double check your saved search results before deploying a solution in production to make sure they are in line with your expectations.

Not sure how costly getting deployments wrong can be to your business? Check out this blog post (with a calculator) to help you make that assessment.

Now, let’s explore solutions to these challenges.

Solutions for Managing NetSuite Customizations

Attempting to manage your transaction saved searches manually between different environments is a difficult process, not to mention frustrating after building the solution in one environment only to have to manually rebuild it again in Production.

The inherent risk of doing this manually is HIGH. Given the almost infinite number of customization options available in any one transaction saved search and even more so if it is part of a larger NetSuite custom solution.

With NetSuite Teams managing the migration of solutions on a frequent basis, NetSuite provides a number of out of box solutions available to manage them. Depending on the customization you are looking to migrate you might leverage features such as “Copy to Account”, “SuiteBundler” and “SuiteCloud Development Framework” more commonly referred to as “SDF”.

Each of these tools have pros and cons, so you should review and see which will be the most effective for your given customization. It is not a one size fits all decision. Copy to Account might be sufficient for a simple transaction saved search, but something more complex might require a different path especially when there are dependencies to consider.

With that, there are alternative solutions to consider to help manage your NetSuite deployments across multiple NetSuite environments. One solution to consider is Salto - you can get more information on the Salto SuiteApp here. The Salto platform allows NetSuite Administrators to easily perform environment comparisons across the environments your company manages. This significantly simplifies the process of identifying potential deployment dependencies. In fact it allows the NetSuite Admin Team to find and address any potential conflicts in advance of deployment, allowing the team to be more proactive in their approach vs addressing issues after the fact.

In addition to streamlining the deployment process, the Salto platform provides the ability to execute rollbacks in the event a deployment needs to be reversed, whether it was pushed inadvertently or issues were found in Production that need to be resolved ASAP. Rollbacks should not happen very often, but when they do there is generally a sense of urgency around them. Having a tool at your disposal to manage this process quickly and efficiently is a game changer in those moments.

Now that you have successfully deployed your custom NetSuite solutions to Production, let’s consider some best practices that NetSuite Administrators should adopt when working with transaction saved searches.

Best Practices When Working With Transaction Saved Searches

1. Automate deployments - You should streamline your deployment process for transaction saved searches. Migrating manually is time consuming and error prone.
2. Be specific (with dates) - Forgetting to set date/period criteria can lead to incorrect results in the “Amount” column of your transaction saved search.
3. Apply standard criteria - Add your standard criteria before adding more specific criteria. This includes setting “Posting” equal to true, selecting the appropriate transaction “Type” and leveraging both “Main Line” and “Tax Line” to avoid an ambiguity in the results.
4. Check security - Before sharing the results, make sure they are restricted to the appropriate audience. There are numerous security features in saved searches, including potential overrides.
5. System performance - Keeping your transaction saved search simple is going to improve system performance, specifically reduce the amount of time for NetSuite to render the results.
6. System notes - By leveraging system notes fields in your saved search you can get more details on transaction records such as who created them, how they were created and what changes were made over time.
7. Expand criteria, limit results - By getting very specific with your criteria and intentionally limiting the number of columns in your saved search results, you avoid the need to export data to Excel for further review and summarization. This can all be managed directly inside NetSuite.
8. Sample check - Prior to sharing your search results be sure to validate a sample of transaction results by cross-referencing the saved search data to the underlying transactions.
9. Consolidated exchange rates - Make sure you have the appropriate setting in your transaction saved search “Results” tab. “Per-Account” is the system default and generally the correct value, but there are occasions when you will want it set to “None” to report on the subsidiary functional currency instead. Avoid the other values.
10. Suite Analytics - When you run into system limitations with your transaction saved searches, such as fields that are not available, attempt to rebuild as a Suite Analytics Dataset. In many cases you will find that Dataset avoids such limitations.

Salto Tip: Check out this FREE NetSuite Administrator training course on Salto Leap to see how you can become a Master NetSuite Administrator and NetSuite guru for your company.

Useful references

• NetSuite Saved Search Documentation
• NetSuite Saved Search Examples
• NetSuite Saved Search Mistakes
• Creating Transaction Saved Searches for Reimport
• Saved Search Email

For more Best Practices to manage your NetSuite customizations, check out Salto’s blog posts that explore some of the things that NetSuite Developers and NetSuite Administrators should be leveraging within the NetSuite ecosystem.

Final thoughts

Transaction saved searches are the most popular saved search type for a reason. They can give business leaders real time insights into different areas of the business to support critical decisions.

NetSuite end users have an obligation to validate the saved search results before sharing them more broadly. This includes restricting the saved search query to the smallest population possible to produce the required results, such as limiting the transaction data or period in the saved search criteria or keeping the number of columns displayed in the results to a minimum. Not only will this simplify the output for users to analyze, but will improve system performance in running the saved search.

As powerful as transaction saved searches are, they are not without limitation. NetSuite Administrators are solving many of these limitations by switching to Suite Analytics datasets and workbooks. If you haven’t explored this out of the box system functionality it might be time to start - you will find them even more powerful than the more traditional saved searches.