Why “Out-of-the-Box” Is Often Misunderstood by Architects

[Abhijeet Upadh2]

Early in my ServiceNow career, I used to defend “out-of-the-box” almost religiously. Over time, I realised most people don’t disagree with OOB—they disagree on what OOB actually means.

Out-of-the-box is not “do nothing and hope the platform magically fits your organisation”. Nor is it blindly rejecting all customisation. In real enterprise programs, OOB is a starting position, not a destination.

What I’ve repeatedly seen fail is teams treating OOB as a compliance checkbox rather than a design principle. They implement standard tables, standard workflows, standard forms—but ignore the operating model around them. As a result, the solution technically stays OOB while becoming operationally unusable. Users then work around the system, and the platform quietly loses trust.

True OOB thinking is about leveraging native patterns—state models, extensibility points, upgrade-safe scripting, configuration over code—while being intentional about where you diverge. Some of the most stable platforms I’ve seen were not “pure OOB”; they were selectively customised with discipline.

The ServiceNow community often debates “custom vs config” as a binary choice. In practice, the real question is: Who owns this deviation, and can we explain it two years from now? If you can’t justify a customisation beyond “the business asked for it,” you’re already creating future debt.

As architects, our job isn’t to defend OOB at all costs. It’s to protect the platform’s long-term health while still enabling real business outcomes. That requires judgement, not dogma.