Customise NetSuite to power your business and maximise efficiency. Learn best practices for successful development.
There is a moment in almost every NetSuite engagement where someone asks whether the system can be made to do a particular thing. The answer is nearly always yes. The more useful question, and the one that separates a healthy NetSuite account from an expensive one, is whether it should be, and if so, by which method.
NetSuite offers several ways to change how it behaves, and they are not interchangeable. Choosing badly is the single most common cause of NetSuite accounts that become slow, fragile and expensive to maintain. This article sets out the options, when each is appropriate, what the real costs are, and how to keep a customised account healthy over the long term.
Nearly every request to change NetSuite can be met at one of three levels, and they differ enormously in cost, risk and durability.
Configuration means using the settings NetSuite already provides. Enabling a feature, defining a custom field, building a saved search, creating a custom form, setting an approval routing rule. No code is written and nothing unusual is created.
Configuration is upgrade safe, reversible and cheap. It is also more capable than most people assume, which matters because a great many requests that arrive labelled as development are actually configuration nobody has explored.
Customisation means using NetSuite's declarative tools to change behaviour without writing script. SuiteFlow workflows are the main example, along with custom records, custom transaction types and more elaborate form logic.
This is still low code, still relatively transparent, and still reasonably upgrade safe. A workflow can be read and understood by an administrator without a developer, which is a genuine advantage when the person who built it has left.
Development means SuiteScript. Real JavaScript executing inside NetSuite, capable of things the declarative tools cannot reach. Complex validation, integrations with external systems, bulk data processing, custom user interfaces.
Development is powerful and carries the highest ongoing cost. Code needs testing after each NetSuite release, documenting so someone else can maintain it, and revisiting when the business changes.
The principle worth holding is straightforward. Solve at the lowest level that genuinely works.
If configuration solves it, configure. If configuration cannot but a workflow can, build the workflow. Only write script when the first two genuinely cannot deliver the outcome.
This sounds obvious and is routinely ignored, usually for one of three reasons. Sometimes the person deciding is a developer, and writing script is what they are good at. Sometimes nobody has taken the time to find out whether a standard feature exists. And sometimes the request was framed as a solution rather than a problem, so nobody stepped back to ask what outcome was actually wanted.
That last one is worth guarding against. A request that arrives as "we need a script that copies the customer's purchase order number onto the invoice" has already decided the method. A request framed as "our customers reject invoices that do not show their purchase order number" leaves room for the cheaper answer, which in this instance is usually a field and a form change.
Consider a common request. Sales staff should not be able to submit an order for a customer whose account is more than sixty days overdue.
At the configuration level, NetSuite has credit limit and credit hold functionality built in. For a good number of businesses this is the entire answer, and it takes an afternoon.
Where the rule is more specific than the standard functionality allows, say it should apply only to certain customer categories or should warn rather than block, a workflow can add that logic. Still no code, still readable by an administrator.
Where the rule depends on data NetSuite does not hold, perhaps a credit score from an external service, script becomes necessary because something has to call out to that service and interpret the response.
Three quite different costs, and the difference between them is entirely in how carefully the requirement was examined before anyone started building.
It helps to know what is available, because the names are not self explanatory.
The configuration layer. Custom fields, custom records, custom forms, custom lists, custom centres. Point and click, no code.
The workflow engine. State based automation triggered by record events, capable of field updates, approvals, emails, record creation and conditional branching. Visual, and readable months later by someone who did not build it.
The scripting platform, currently SuiteScript 2.1. Several script types exist and the difference matters. User event scripts run on the server when records are created, loaded or saved. Client scripts run in the browser as a user works. Scheduled scripts run on a timetable. Map/reduce scripts handle bulk processing across large record volumes. Suitelets build custom pages. RESTlets expose endpoints external systems can call.
The integration layer, offering both SOAP and REST web services for external systems to read and write NetSuite data.
Reporting and analytics, spanning saved searches, reports, dashboards and workbooks. A great deal of what gets requested as custom development is a reporting requirement that this layer already covers.
NetSuite limits how much processing any single script can consume, expressed as governance units. Different operations cost different amounts, with record loads and saves being the expensive ones.
Exceed the limit and the script stops. This is the most common cause of a customisation that worked perfectly at go live and fails eighteen months later, because the business grew and the script now processes more records than its budget allows.
The implication is architectural rather than incidental. Anything expected to handle volume should be built as a map/reduce script, which is designed to yield and resume, rather than a scheduled script that will eventually hit its ceiling. That decision is cheap at design time and expensive to retrofit.
When you commission development, governance handling is a fair thing to ask about. A developer who has thought about it will tell you what happens at ten times current volume. One who has not will tell you it works.
The build price is the visible cost and rarely the largest one.
There is release testing. NetSuite updates twice a year, and every customisation should be checked against the release preview account before it reaches production. Ten customisations make that a manageable task. Sixty make it a project.
There is the upgrade constraint. Heavily customised accounts adopt new NetSuite functionality more slowly, because each new feature has to be assessed against existing customisations. Businesses in this position frequently end up paying to maintain a custom solution to a problem NetSuite solved natively two releases ago.
There is knowledge risk. Undocumented script is a liability the moment its author is unavailable. This is not hypothetical, it is the single most common finding when an external team takes over an account.
There is performance. Poorly written user event scripts slow down every save of the record they attach to. Users experience this as "NetSuite is slow" without connecting it to a customisation built two years earlier.
And there is compounding. Customisations interact. Two workflows touching the same field in different circumstances produce behaviour neither author anticipated, and diagnosing it costs more than either build did.
A few patterns indicate the ladder has not been respected.
None of these are fatal, and all of them get worse if left. Periodic review, asking of each customisation whether it is still needed and still the right method, is unglamorous and repays itself.
Where development genuinely is the right answer, a few practices separate work that lasts from work that becomes a problem.
Development belongs in a sandbox account, tested there, and promoted to production deliberately. Building directly in production is a discipline failure, and it happens more than it should because sandbox refreshes take time and deadlines press.
The SuiteCloud Development Framework allows customisations to be defined as source files, version controlled and deployed as a package. That means you can see what changed, when, and by whom, and roll back cleanly.
Documentation written six months later is fiction. What the customisation does, why it exists, what triggers it, what it assumes, and what would break if it were removed. Two paragraphs written at the time are worth more than a full specification written from memory.
A script that fails silently is worse than one that fails loudly, because the business carries on believing the process ran. Errors should be logged and, for anything material, should notify someone.
Ask what happens at ten times the current record count. Governance limits and processing windows are both easier to design for than to retrofit.
Where the same rule is enforced by a workflow and a script and a form validation, three things have to change when the rule changes, and one of them will be missed.
Testing NetSuite customisations tends to be lighter than it should be, largely because there is no obvious harness for it. A few habits improve the odds considerably.
Test the failure paths, not just the happy one. What does the script do when a required field is empty, when an external service times out, when the record is edited by two people at once?
Test with realistic data volume. A map/reduce script that behaves perfectly across fifty records may reveal quite different behaviour across fifty thousand.
Test with the actual roles that will use it. Permission errors are among the most common post deployment surprises, because development is usually done with administrator access.
And keep a short regression list. The handful of things to check after each NetSuite release, written down, so release testing does not depend on someone remembering what matters.
A large proportion of NetSuite development is integration, and it carries risks the rest does not.
The main one is that you now depend on something outside your control. The other system changes its API, has an outage, or returns data in a shape you did not anticipate. Integrations should assume this will happen rather than assume it will not.
Retry logic matters, and so does idempotency, meaning the same message processed twice does not create two records. Duplicate transactions from a retried integration are among the more painful problems to unpick after the fact.
Visibility matters as well. Someone should be able to answer whether the integration ran this morning and whether anything failed, without reading script logs.
It is worth naming the requests that look like development and are not, because they come up constantly.
Reporting requirements almost always sit with saved searches, reports or workbooks. If someone is exporting to a spreadsheet to produce a figure, the usual cause is that nobody built the search rather than that NetSuite cannot produce it. This is the territory our report writing service covers, and it resolves more perceived gaps than any other single intervention.
Approval requirements are usually SuiteFlow. Data entry frustrations are usually custom forms, field defaults and role specific views. Users asking for a simpler screen generally need a custom centre rather than a Suitelet.
And a good number of requests are training rather than technology. Where users have built a workaround because they were never shown the standard path, structured training is faster and cheaper than building the workaround into the system permanently.
A partner who pushes back on unnecessary development is worth considerably more than one who quotes everything, even though the second is more pleasant to deal with in the short term.
Development rarely stands alone. Ongoing capability to configure, maintain and extend the account is what NetSuite administration provides, and most requests should land there before anyone reaches for script. Where the requirement genuinely calls for code, NetSuite customisation and development is the right engagement, and where you need that capacity available continuously rather than project by project, managed services is the usual arrangement.
Where an account has accumulated customisations to the point that it is difficult to change safely, the honest starting point is often not more development at all. An implementation rescue that reduces what is there is frequently worth more than anything added on top.
When a request arrives, work through it in order. State the outcome the business wants rather than the solution someone has already imagined. Ask whether standard NetSuite already does it, and be genuinely thorough about that. Ask whether configuration reaches it. Ask whether a workflow reaches it. Only then consider script.
And before committing to any of it, ask what it costs to maintain for five years, not just to build. That single question changes a surprising number of decisions.
NetSuite is designed to be adapted, and businesses that adapt it thoughtfully get considerable value from doing so. The ones that struggle are almost never the ones that customised too little.
If you are weighing up a customisation and want a straight answer about whether it is the right method, get in touch.
