Unpopular Opinion: I prefer to use scripted searches in my SuiteScript rather than referencing existing, external saved searches.

Here’s why.

Ease of Change Myth

The most common reason I hear for referencing saved searches rather that creating searches in the code is that if the logic or criteria for the search changes, it’s easier to update an existing saved search than it is to update the code that contains that search.

I don’t disagree that it is simpler, but if you have proper change controls in place, that saved search should be considered part of your code and you should be using the same rigor when you change the saved search. It should still be tested by a dev, go through QA and tested by end users before making that change in production.

The vast majority of saved searches are created on the fly and do not need review and change management processes around them. The minute you prefix a search with something like “SCRIPT - DO NOT CHANGE”, your change management steps should apply.

Security

If the search is included in the script, then you have restricted access to that search to only those with the ability to update code in NetSuite.

Just because you put “SCRIPT - DO NOT CHANGE” in the saved search title doesn’t mean people won’t modify, or even delete, the search. Remove a column … even change the order of columns and you can affect how the script works.

Readability

Imagine you have a scheduled script that is supposed to send an email to all customers when a certain condition is met. You are notified from the business that CustomerABC is not receiving the email in question.

If the search is created within the script, I can immediately see the criteria for that search and investigate why the customer in question is not being picked up.

If the script is referencing an external saved search, the ID of that search is likely stored in a script parameter. So I need to find the script parameter in the code, switch to NetSuite and find the script record, go to the deployment, and note the value in the script parameter.

Sometimes that parameter only has a script ID. In that case I need to open another search and replace the ID in the URL. Sometimes it shows the name of the search and frequently I don’t see that search in the UI. Non-public searches created by administrators are sometimes not visible to other administrators so finding the search can take time.

Having the logic for the query right next to the code that uses the results of that query is a huge time saver.

Versioning

When things change and something goes wrong, being able to go back in time to see what a search looked like before the change is extremely important. With source control, it’s trivial to see the original search and compare it with the current version.

Saved searches have an audit trail tab that will list everything that has changed, but it only allows you to view one change at a time with a list of property names showing their old and new values. It can be difficult to piece together an entire change

Saved search definitions can be exported with SDF allowing you to include them in your source control system, but unlike other SDF objects, the the actual definition is encoded and not as easily versioned.

Performance

I’ve heard many consultants say that saved searches perform better than scripted searches but I have never seen any documentation to support this. I am aware that NetSuite can add database “hints” to help with saved search performance, and I’ve heard that this can happen automatically for saved searches.

However, if we load an existing saved search in our script and modify the filters or columns before we execute it, we can argue that performance gains from any database hint is likely lost as we have changed the database’s execution plan for that query.

Here’s the unpopular part: Even if they perform better, I’d argue that the performance gain is negligible to the benefits of having that logic in my script where I need it.

Summary

It’s a preference for sure. Some people prefer saved searches in the UI. Some people prefer scripted searches. Whatever you need to do to build features and functionality for your business users, do that.

Please think about the impact downstream for future developers, including yourself when you have to revisit code you wrote 6 months ago.