Skip to main content
resources

June 24, 2026

NetSuite bundle code vs. your own customizations: what a health check should ignore

Open the script list in a mature NetSuite account and you will see hundreds of deployments. Here is the thing most health checks miss: most of them are not yours.

Two kinds of code, one list

NetSuite mixes two very different things in the same script list:

  • Your customizations. The scripts, workflows, and fields your team or your consultants built for your specific account. This is what you can change, and what you are responsible for.
  • Bundle and SuiteApp code. Packaged software installed from a vendor (Celigo, Boomi connectors, industry SuiteApps, and so on). The vendor maintains it and ships updates. You configure it, but you do not edit its scripts.

They sit side by side in the same list, and nothing obvious tells you which is which.

Why the distinction matters

You can only act on your own customizations. So a finding in vendor bundle code is noise. It is not yours to fix. The vendor patches it through their release cycle. If your audit reports it as a problem for you to solve, it is wasting your attention and hiding the findings that actually matter.

In real accounts we have scanned, the large majority of scripts turned out to be vendor bundle code, with only a fraction being the customer's own. An audit that does not separate the two produces a report that is mostly about code you cannot touch. The handful of scripts that are genuinely yours, and genuinely risky, get buried.

What "focus on what you can change" looks like

A good health check does the separation for you. It identifies which scripts live in vendor bundle folders and which are your own, then runs the risk analysis only on the ones you can act on. Your report becomes short, relevant, and actionable, instead of a long list you have to manually filter.

This is also why script-level code review should only apply to your own scripts. Reviewing bundle code you cannot edit is pointless, and often the account does not even have permission to read it.

How SuiteRX handles it

SuiteRX separates your own customizations from vendor-managed bundle code and runs its risk checks only on the scripts you can actually change. When you review a specific script's source, it skips bundle-managed code by design. The result is a report about your account, not your vendors'. Related reading: finding orphaned scripts and governance limits.

See a live sample report, no email required, or run one on your account.

When the customizations that are yours need cleaning up, the NetSuite team at Adaptive Solutions Group can help you do it.

Frequently asked

What is the difference between bundle code and custom scripts in NetSuite?+

Custom scripts are the customizations your team or your consultants built for your account. Bundle code (and SuiteApp code) is packaged software installed from a vendor like Celigo, and it is maintained by that vendor. You can configure a bundle, but you generally cannot and should not edit its scripts.

Why does a NetSuite audit need to tell them apart?+

Because you can only act on your own customizations. Flagging problems in vendor bundle code is noise: it is not yours to fix, and the vendor patches it through updates. A good health check separates the two and focuses on the scripts you can actually change.

How much of a NetSuite account is bundle code?+

Often most of it. In real accounts we have scanned, the large majority of scripts were vendor-managed bundle code and only a fraction were the customer's own. Scanning everything without separating them buries the findings that matter under code you cannot touch.

See it on your own account.

SuiteRX checks everything in this guide, read-only, and hands you the report.