Why Customisation Is Not the Enemy—Unowned Customisation Is

[Abhijeet Upadh2]

Somewhere along the way, “customisation” became a dirty word in ServiceNow conversations. I understand why—but the platform was never designed to be used without customisation. It was designed to be extended responsibly, in a way that balances business outcomes with long-term platform health.

The real problem isn’t custom code. It’s custom code with no owner, no context, and no lifecycle. I’ve reviewed multiple production instances where perfectly reasonable customisations caused outages or upgrade failures simply because no one remembered why they existed, what problem they originally solved, or whether they were still relevant. The risk wasn’t the code itself—it was the absence of accountability.

Unowned customisation usually starts innocently. A developer solves a pressing delivery problem. The solution works, the project moves on, and documentation is deferred “until later.” Months later, another team unknowingly builds a dependency on it. Years later, no one can confidently say whether removing it will break something critical. At that point, the customisation becomes untouchable—not because it’s complex, but because it’s orphaned.

Ironically, I’ve seen organisations aggressively restrict scripting while allowing uncontrolled configuration sprawl. Thousands of UI policies, workflows, catalog rules, and condition builders—technically “OOB,” yet completely undocumented and poorly understood. From a risk perspective, this is often worse than well-written custom code.

Healthy platforms don’t avoid customisation. They govern it. They treat custom logic as a product asset, with named owners, design rationale, review cycles, and clear deprecation paths. They routinely ask a simple but powerful question: Who is accountable for this two years from now?

Customisation isn’t the enemy. Neglect is.