Your NetSuite Preview Test Is Reassurance-Seeking

NetSuite 2026.2 preview is live. Most teams will not open it.

A few will log in for an hour, click through some menus, confirm it "looks fine," and close the tab. That is not testing. That is reassurance-seeking with a browser.

When the release hits your production account, something will break. You will spend an afternoon debugging a script that touches a record API NetSuite quietly changed. You will find out during a live transaction, not during preview.

The Part Everyone Skips

Before you log into preview, read the release notes. All of them. The deprecation section specifically.

NetSuite buries the risky changes. The release notes are long and organized for a general audience. The line that matters is usually in the middle of a section about something else.

What you are looking for: changed field behaviors, deprecated APIs, altered transaction flows, new required fields, modified search behavior. The release notes tell you where to point your attention in the account. Do not go fishing without them.

What to Actually Test

Not everything. That is the trap.

Teams that do engage with preview try to retest their entire system. They run out of time, get fatigued, and miss the thing that matters. Narrow the scope.

Test the scripts that touch the areas NetSuite changed. If 2026.2 modifies how vendor bill approval workflows behave, pull your SuiteScript 2.x scripts that use N/record against vendorbill records and run them in preview. Not all your scripts — the ones in the blast radius.

Test your integrations. If you have a Boomi process or a custom middleware layer hitting the REST API to create or update transactions, point it at your preview account and run it end to end. REST API surface changes are documented but they happen. Find out before production does.

Test the saved searches that feed dashboards or that your scripts depend on at runtime. Search behavior changes occasionally, and N/search returning unexpected columns or different result ordering will not throw an error. It will silently produce wrong data and you will spend three days blaming the script before you think to check the search.

Test any workflows in areas the release notes flagged. Workflow state transitions on records that NetSuite modified deserve a real transaction run — not a visual inspection of the workflow diagram.

Build the List Now, Use It in Six Months

The thing that makes preview testing pay off is not what you do this cycle. It is what you document.

After this release, write down what you tested and why — which scripts, which integrations, which searches, mapped to which sections of the release notes. That list becomes your starting template for 2027.1. You adjust it based on what that release changes, but the structure is already there.

This is maybe an extra thirty minutes now. It saves you from rebuilding the process from scratch twice a year.

Had a client whose release test process was a single Slack message asking if anyone had checked preview yet. The answer was always no. They had a production incident within the first week of every major release — wrong calculations, a script erroring on a new required field, a saved search dropping a column. Small things that compound fast in a live environment.

The test list fixed that. Not because it was comprehensive. Because it was targeted and it existed.

A reasonable template for each release:

• Customizations touching record types or APIs the release notes flagged
• Integration endpoints running against the preview account with real payloads
• Saved searches used in scripts or high-traffic dashboards
• Workflows on modified transaction types
• Any feature your team is actively relying on that the release notes mentioned at all

Bottom Line

Preview testing is not about confidence. It is about narrowing the window where NetSuite can surprise you in production.

Read the release notes first. Test the scripts and integrations in the blast radius of what changed. Check your dependent saved searches. Document what you tested and why — not for audit trail purposes, but so you do not redo this work from scratch every six months.

The list is the discipline.