Every ServiceNow programme eventually has the same argument. The business wants a field, a screen or a behaviour that the platform does not provide. Someone says "we should stay out-of-the-box." Someone else says "the platform should fit how we work, not the other way round."
Both are right, which is why the argument never resolves on principle. It resolves on cost — and the problem is that the cost arrives years after the decision, by which time nobody remembers who made it or why.
Why "always stay OOTB" fails as a rule
Taken literally, it means telling a regulated business it cannot capture a field its regulator requires. Nobody actually means that. What they mean is "customisation has hurt us before" — which is a reasonable scar, but a poor decision procedure.
Applied rigidly, the rule pushes work outside the platform rather than eliminating it. The requirement does not evaporate; it reappears as a spreadsheet, a shadow database or a manual step nobody logs. You have not avoided the cost. You have moved it somewhere you cannot see or govern.
Why "the platform should fit us" fails too
The opposite instinct fails more slowly and more expensively.
Every customisation is a permanent claim on future capacity. It has to be regression-tested at every upgrade, understood by every new team member, and considered by everyone who touches an adjacent feature. One is trivial. Two hundred is a platform where upgrades take a quarter and nobody can safely change anything.
The cost is not the build. It is the compounding maintenance, and it is invisible at the moment of decision, which is exactly why it accumulates.
The five questions worth asking
Before building anything beyond configuration, answer these — in writing, where a future architect can find them.
1. What breaks if we do this the standard way?
Not "what is worse", but what actually breaks. A team preferring a different field order is not a break. A statutory retention requirement the standard model cannot express is. Most of the time this question alone settles it, because the honest answer is "nothing breaks, people would just prefer it".
2. Is this a process problem wearing a platform costume?
A surprising share of customisation requests exist to preserve a workflow that only made sense in the tool being replaced. The approval chain has four steps because the old system could not do parallel approvals — not because the business needs four steps. Automating an inherited inefficiency makes it permanent.
3. What is the upgrade surface?
There is an enormous difference between a Business Rule on a custom table in a scoped application, and a modification to a core ITSM form. The first is nearly free at upgrade time. The second must be reviewed, tested and possibly reworked at every release, forever. Same effort to build; entirely different lifetime cost.
4. Who owns this in three years?
Customisation is a maintenance commitment. If the answer is "the consultant who built it", the real answer is "nobody". That is not automatically disqualifying, but it must be priced in — as documentation, handover and internal capability, not just build hours.
5. What is the reversal cost?
If this turns out to be wrong, how hard is it to undo? A scoped application can be deactivated. A modified core table with two years of data written through it cannot. Prefer decisions that stay reversible, and be far more careful with the ones that do not.
Make the decision visible
The single most valuable practice here is not a rule about customisation. It is recording the decision.
A short architecture decision record — what was requested, what standard would have required, why the deviation was accepted, who accepted it, what it will cost to maintain — takes fifteen minutes to write and answers a question that will otherwise be asked repeatedly for years.
Without it, every future team inherits a platform full of choices with no rationale attached. They then face an impossible position: they cannot safely remove the customisation, because they do not know what it was for, and they cannot confidently extend it for the same reason. That, more than any single build, is how platforms become brittle.
A working rule of thumb
Not a policy, but a reasonable default:
- Configuration — do it freely. That is what it is for.
- Extension in a scoped application — do it when there is a real business case. The upgrade surface is small and the reversal cost is low.
- Modification of core tables and behaviour — treat as an exception requiring a named owner, a written decision record and an accepted maintenance cost.
- Replicating a legacy process the platform already solves differently — resist, and go back to question two.
The goal is not the smallest possible customisation footprint. It is a footprint where every item can be explained by someone still at the company.
Reviewing an environment where these decisions were made years ago and never written down? Customisation footprint is one of the eight areas covered by our Platform Health Check.