Station 9 of 10
Customisation and governance in Oracle NetSuite
What you leave this station with
Placing any customisation request on a known rung, understanding the governance limits before hitting them, and designing something that does not break at an upgrade.
At station eight you learned the limits that cannot be crossed. This station draws a limit of another kind: where configuration ends and code begins.
In this product the question has a particular shape, because the upgrade happens twice a year, automatically, and carries no decision. So there is no customer base stranded on an old release, and no upgrade project every three years.
The price of that is a ceiling on customisation. It is a fair bargain — provided you know you struck it.
The ladder — six rungs
Place any request on this ladder before discussing it. The rule: do not climb a rung while you can stay below it.
| The rung | What it is | Who does it | What it needs |
|---|---|---|---|
| 1. Screens and roles | What each role sees and what is hidden from it | The consultant | Nothing |
| 2. Custom fields and records | Data the product does not carry | The consultant | Design, not code |
| 3. The saved search and its dashboards | Very nearly every reporting question | The consultant | A skill, not programming |
| 4. A workflow with no code | Approvals, states and alerts | The consultant | Logic drawn out |
| 5. A ready-made application | A standard need somebody else built | It is bought | Assessing the publisher |
| 6. A written script | Logic that cannot be built any other way | A developer | JavaScript and governance |
Read the third rung twice. Most of what gets asked for on projects under the name “a custom report” falls on it, and gets built on the sixth because nobody asked.
The fourth rung — approval, and station five’s promise returning
At station five it was said that the credit hold is a policy decision, and that the question is not what the limit is but who releases it. Here the answer gets built.
A workflow actually stops the document: it leaves a state that can be executed for a state waiting on a decision, and it does not move until whoever holds the right approves.
Four things are decided before it is built:
On which document, under what condition, who approves, and what happens if they are away.
The fourth is the one forgotten, then discovered on the first annual leave when the whole company’s documents stand still on one man’s absence. The remedy is a substitute approver designed on day one.
This is an entirely functional rung — with not one line of code — and its control effect is larger than most of what gets written in code.
The ceiling: the governance limits
Here is the idea that separates somebody who read about the product from somebody who understood it.
You never touch the base code. And the script you write runs under governance limits that cap what a single script may execute — how many operations it performs, how much it reads and writes, and how far it extends before it is stopped.
Which means in practice that the programming question here is not “does it work?” but “does it work at my volume?”
A script that passes over a hundred records runs without complaint; the same script on a hundred thousand records stops. And the fix is not merely writing more cleverly; the fix is a different execution pattern that splits the work into batches.
The design conclusion to be written down on day one: estimate the volume before you write, not after the test fails on production data.
Anybody intending to rebuild non-standard processes inside this system hits the ceiling in the sixth month — and the shock is not that a ceiling exists; it is that it was not read before somebody built on top of it.
Why the ceiling exists at all
Because the upgrade happens to you twice a year whether you agree or not.
And one version for everybody means what you write may not disable a shared environment. So governance is not a punishment; it is what makes the automatic upgrade possible.
| What you gain | What you pay | |
|---|---|---|
| The upgrade | Automatic, with no project | You cannot defer it |
| The base code | Does not break | Is not modified |
| The script | Lives across releases | Runs under limits |
Read the two columns together once — the product’s entire philosophy sits between them.
When it is bought rather than written
Between configuration and code sits a rung many people skip: the ready-made application.
Three questions before installing any of them: who publishes it, is it managed and updated automatically or left to you, and does it work alongside the rest of your applications?
The second question is the decisive one — and you saw at station eight what it means for a localisation application to be managed.
The sentence said in a meeting
“Which rung does this request fall on?”
One sentence that shortens a whole meeting. Anybody asking it turns a discussion about wishes into a discussion about cost, and anybody who does not leaves with a customisation list three quarters of which was a saved search.
And the most dangerous thing said on a project: “this is simple, we will write it.” Writing is faster than looking for the configuration, and its price is paid at every upgrade afterwards.
What you actually do at this station
- Write out the six rungs from memory, and what each rung needs.
- Take ten real customisation requests — from your work or from a written imagined case — and number them onto the rungs, and count how many sit above the fourth.
- Design a complete approval workflow with its four answers, including a substitute approver.
- Write one requirement that genuinely deserves a script, and explain why the five rungs below it do not suffice.
- Estimate that requirement’s expected record volume in three years’ time, and write how your design changes because of it.
- Assess a ready-made application with the three questions, and write your decision with its argument.
The three commonest errors
One: writing a script for what a saved search answers. It works from day one, and it is maintained for ever.
Two: ignoring volume in the design. It succeeds in testing on tens of records, and stops in production on tens of thousands.
Three: planning to rebuild non-standard processes inside the system. It looks possible in the first month, and hits the ceiling in the sixth — and the ceiling was published before it started.
What customisation discipline does to the real cost of ownership is set out in the Oracle NetSuite guide.
The acceptance test for this station
- Write the six rungs, and which of them absorbs most requests.
- Explain what the governance limits mean, and why the question becomes “does it work at my volume?”
- Explain the relationship between the automatic upgrade and the ceiling, and what you gain and what you pay.
- Present the approval workflow you designed and its four answers.
- Name a requirement that deserves a script, and why the rungs below it do not suffice.
What comes next
You know where configuration ends. The last station gathers the path into something that can be shown: certification and the first job — with an annual assessment that drops certifications for no want of knowledge in their holders, and a portfolio built with no environment.