SuiteScript 2.1 development
SuiteScript written by people who count governance units.
Most SuiteScript that gets delivered works on ten records and fails on ten thousand. We write against documented APIs, budget governance from the start, and log enough that you can diagnose a failure without calling us.
What SuiteScript is
SuiteScript is NetSuite's JavaScript-based extension platform. It lets code run in response to record events, on a schedule, in the user's browser, or as a callable endpoint — which is how nearly every serious NetSuite customization ultimately works.
The current version is SuiteScript 2.1, running on a modern JavaScript
engine with support for let, const, arrow functions, template
literals, and async patterns. SuiteScript 2.0 introduced the modular
define architecture. SuiteScript 1.0 is legacy and shouldn't be used for new
development, though plenty of accounts still run it — migrating that code is work we do
regularly.
The script types, and when each one is right
User Event scripts
Run on the server when a record is created, loaded, updated, or deleted, across
beforeLoad, beforeSubmit, and afterSubmit. This is
where validation, field calculation, and related-record creation belong. The common
mistake is putting expensive work in afterSubmit on a high-volume record type
and discovering the cost at month end.
Client scripts
Run in the browser as the user works: field change handlers, sublist validation, dynamic sourcing, and save-time checks. Good for responsiveness. Never rely on them for data integrity — anything that must be true has to be enforced server side, because client scripts don't run on CSV import, web services, or other scripts.
Map/Reduce scripts
The right tool for volume. Map/Reduce parallelises across queues and yields automatically when governance runs low, resuming exactly where it left off. If you're processing thousands of records, this is almost always the answer — and it's frequently what we replace a failing Scheduled script with.
Scheduled scripts
Sequential background processing on a defined schedule. Simpler than Map/Reduce and appropriate when order matters or volume is low. Requires you to handle rescheduling yourself when governance runs out, which is the part people forget.
Suitelets
Custom server-side pages inside NetSuite: bespoke search interfaces, bulk-action screens,
approval consoles, and forms that native NetSuite can't produce. Built with the
N/ui/serverWidget module so they look native, or with custom HTML where
they need to look better than native.
RESTlets
Custom REST endpoints for external systems to call. Where SuiteTalk's standard operations don't fit — because you need custom logic, a specific payload shape, or fewer round trips — a RESTlet is the answer. Most of our integration work uses them.
Portlets, Mass Update, and Workflow Action scripts
Dashboard portlets for custom widgets, Mass Update scripts for scripted bulk edits, and Workflow Action scripts for dropping a piece of code into an otherwise no-code SuiteFlow workflow — often the cheapest way to solve a problem that's 90% configurable.
Governance: the thing that separates working code from durable code
NetSuite limits how much processing a single script execution can consume. Every API call costs units, and every script type has a ceiling. Exceed it and you get a usage limit error — usually in production, usually at volume, usually not in testing.
The most common cause is a per-record lookup inside a loop. Each
search.lookupFields call is cheap on its own, so the pattern looks fine
in testing on a handful of records — then the same script meets four thousand and hits
the ceiling. Retrieving the same data as a single set with SuiteQL changes the shape of
the problem rather than shaving milliseconds off it. We
benchmarked the two modules
and found per-call timing very close between them, which is exactly why the number of
calls matters more than the choice of module.
If you have a script that works in sandbox and fails in production, governance is the first place to look. It's also the most common reason we get called about someone else's code.
How we write it
- Documented APIs only. Undocumented behaviour is what breaks at release time.
- Governance budgeted before coding. We work out the unit cost at expected volume, not after.
- Real logging. Structured
N/logoutput at meaningful checkpoints, so a failure at 3am is diagnosable from the execution log. - Error handling that surfaces. Failures notify someone instead of dying silently in a queue.
- Comments and handover docs. Written for the person who maintains it after us — possibly you.
- SDF or bundle deployment. Version-controlled where your setup supports it.
Common SuiteScript projects
- Rewriting Scheduled scripts as Map/Reduce to stop volume failures
- Replacing loop-based lookups with SuiteQL for performance
- Migrating SuiteScript 1.0 to 2.1
- Automated transaction creation across record types
- RESTlets for e-commerce, 3PL, and CRM integrations
- Suitelets for bulk operations the UI doesn't support
- Complex pricing, commission, and allocation calculations
- Debugging and auditing scripts you inherited
Frequently asked
Can you fix SuiteScript another developer wrote?
Yes, and it's a large share of what we do. We'll review it first and tell you honestly whether repairing it or rewriting it is cheaper — sometimes the existing code is fine and the deployment configuration is the problem.
Do you provide the source code?
Always. You own it. It arrives commented, with deployment notes, and you're free to hand it to anyone else afterwards.
How do you test before deploying to production?
Development happens in your sandbox against realistic data volumes, including deliberate volume tests to expose governance issues. You test it yourself for as long as you need. There's no sign-off deadline.
What is SuiteQL and why does it matter?
SuiteQL is NetSuite's SQL query interface, available through the N/query module. It retrieves large data sets in a single call rather than record by record, which is often the difference between a script that completes and one that hits the governance ceiling.
Can you work with our internal developers?
Yes. Some clients use us as an extra pair of hands during peak periods, others for code review and architecture guidance while their own team writes the implementation.
Governance errors don't fix themselves.
Fixed price, source code included, and no charge if it doesn't solve the problem.