Customization vs. Configuration: The Most Important Conversation a ServiceNow BPC Can Have
If you’re a BPC or transitioning to become one, you’ll more than likely work on implementation projects that follow ServiceNow’s practice of OOB (out-of-the-box) implementations. Eventually, you’ll hear some version of this request:
“We just need a small customization.”
As a ServiceNow Business Process Consultant (BPC), that sentence should immediately trigger curiosity, caution, and a few clarifying questions. Because more often than not, what a stakeholder means by “customization” and what ServiceNow defines as customization are two very different things.
Understanding — and teaching — the difference between configuration and customization isn’t just a technical concern. It’s one of the most important parts of protecting platform health, managing long-term cost, and building trust with your stakeholders.
Let’s break it down…
Configuration vs. Customization: What’s the Actual Difference?
Configuration: Working With the Platform
Configuration means using ServiceNow’s out-of-the-box (OOB) capabilities as intended:
Form layouts and UI policies
Business rules (within reason)
Client scripts (sparingly)
Flow Designer
Choice lists
State models
Roles and ACLs
Notifications and templates
Dashboards and reports
Per ServiceNow, configuration respects the platform’s best practices. It’s flexible, powerful, and upgrade-safe.
Customization: Changing the DNA of the Platform
Customization involves altering core behavior in ways ServiceNow didn’t intend:
Modifying OOB scripts directly
Overriding base tables or core logic
Hard-coded solutions that bypass standard processes
Heavy scripting where configuration would work
Replacing OOB workflows instead of extending them
Customization almost always includes hardcore coding.
Why Stakeholders Struggle With This Distinction
From a stakeholder’s perspective:
They want the tool to match their process (implementations aren’t done to duplicate their current process, it’s done to improve their current process based on their business needs).
They don’t care how it’s built, only that it works
“Customization” sounds more powerful and tailored
From a BPC perspective:
You’re thinking about upgrades, maintainability, and scale
You know today’s shortcut is tomorrow’s technical debt
You’ve seen one “small change” snowball into months of rework
Your job isn’t to say no. Your job is to translate. It’s to figure out what other configurable solutions there is that can meet the customer’s need.
How to Teach Stakeholders the Difference (Without Sounding Technical)
Use Impact-Based Language
Instead of:
“That requires customization.”
Try:
“That approach would make upgrades harder and more expensive long-term.”
Instead of:
“We shouldn’t change the base table.”
Try:
“If we change that, future ServiceNow updates could break this functionality.”
Stakeholders don’t need technical depth — they need business impact.