The goal is not to eliminate customization. The goal is to make every platform change earn its place.
Most ServiceNow customization debates start with the wrong question:
Should we configure it or customize it?
That sounds sensible, but it focuses on implementation mechanics instead of outcomes. A configuration change can create years of problems with reporting, security, ownership, and upgrades. A well-contained custom development can be the cleanest solution available.
The real question is not how something is built.
The real question is:
- What problem are we solving?
- What consequences will this create?
- Who will own the result?
This is my practical interpretation of ServiceNow's Business-Smart Customization framework based on what I have seen in enterprise implementations. It is not a replacement for the official guidance. It is an opinion on how to make better platform decisions without turning every request into a governance ceremony.
The Four Questions I Use
Before discussing configuration, Flow Designer, scripting, Workspace components, integrations, or custom applications, I ask four questions:
| Question | What I'm trying to establish |
|---|---|
| 1. Is there a justified need to act? | Is the problem real and supported by evidence? |
| 2. Is this the right design? | Have we evaluated alternatives and chosen the smallest coherent solution? |
| 3. What could make the design unacceptable? | What risks are introduced, and who needs to be involved? |
| 4. Who owns the result? | Who will own the data, behavior, lifecycle, and support obligations? |
Important: These questions do not produce a score. They structure a conversation. Unlike a governance checklist, they work equally well for a small local enhancement and a major platform decision.
Start With Standard, But Don't Worship It
Standard capabilities should always be the starting point because ServiceNow manages their lifecycle.
But standard does not automatically mean correct.
A common architecture mistake is treating OOTB as the objective rather than treating it as the starting point. Standard capabilities reduce lifecycle ownership and often provide the fastest path to value.
Example: Employee Center Search
Users complain they cannot find services or knowledge articles.
The wrong response is immediately building a custom search experience.
The better response is reviewing content quality, taxonomy, metadata, synonyms, search configuration, and user behavior first.
Sometimes the answer already exists inside the platform. Sometimes it does not. Business-smart customization starts with understanding the baseline before introducing anything new.
Standardization Also Creates Debt When It Does Not Fit
Over-customization is easy to spot. You can see the scripts, fields, integrations, Workspace components, flows, and upgrade effort it leaves behind.
Over-standardization is harder to see.
However, if the platform cannot support legitimate business needs, users will find another way to get the work done.
The process moves into spreadsheets, shared mailboxes, Teams chats, personal trackers, and side databases. The ServiceNow instance remains technically clean, but the actual business process becomes fragmented, inconsistent, and difficult to govern.
Example: Catalog Request Approvals
A customer wanted additional information collected in the "shopping cart view" before request fulfillment.
The enhancement was rejected because the organization wanted to remain strictly OOTB.
The result was not simplification.
Managers started collecting information through email. Fulfillment teams maintained spreadsheets to compensate for missing context. Reporting became unreliable because part of the process lived inside ServiceNow and part lived outside it.
The platform remained standard. The operating model became customized.
A platform users actively avoid is still a platform problem.
This does not mean every business request deserves customization. It means "standard" is not automatically the lowest-risk option.
Business-smart decisions weigh two types of debt: the debt of changing the platform and the debt of refusing to change it.
Stop Governing by Object Type
One of the most common mistakes in ServiceNow governance is assuming implementation type equals risk.
It does not.
Terms such as configuration, customization and custom development describe how something is built. They do not reliably describe its impact.
The same implementation mechanism can create very different consequences depending on where it is applied.
Example: Two Very Different Fields
Request A
- Temporary display-only field
- Scoped application
- No reporting dependency
- No integrations
- Single delivery team
This is often a local design decision.
Request B
Add a new Business Service Criticality field to the Incident table.
- Cross-product reporting impact
- Integration dependencies
- Potential conflicts with the ServiceNow Common Service Data Model (CSDM)
- Data ownership concerns
- Long-term governance obligations
This is usually an architecture discussion.
Technically, both requests are "just a field."
Architecturally, they are completely different.
Example: Two Very Different Platform Changes
Change A
A simple client script adds choice values on demand and hides a local field within a scoped application.
Impact is limited, isolated, and easy to reverse.
Change B
A customization changes Incident state behavior used by multiple business units, dashboards, integrations, SLAs, and reporting structures.
The technical implementation may still look small. The organizational impact is not.
Many governance processes automatically treat code as high risk and configuration as low risk.
Real-world platform failures rarely follow those categories. A single Business Rule on Task can create more long-term complexity than an entire scoped application. A small Flow Designer change can have greater business impact than thousands of lines of isolated custom code.
What Actually Matters
Instead of asking:
- Is this configuration?
- Is this customization?
- Is this code?
Ask:
- Where does the change live?
- What depends on it?
- How far can failure spread?
- How difficult is it to reverse?
- Who will own it long term?
Judge the consequence, not the label. The implementation method provides context. The consequence determines the governance response.
Scoring Models Can Help. They Cannot Replace Judgment.
Many organizations use governance scorecards.
There is nothing inherently wrong with that.
Scoring models can help structure discussion.
The problem starts when the score becomes the decision.
Example: When the Score Says Yes and the Architecture Says No
A proposal scores highly for business value, executive sponsorship, and user impact.
The implementation also changes shared User attributes used across multiple products.
No spreadsheet can decide whether that tradeoff is acceptable. Architectural judgment is still required.
Good governance makes judgment visible. Bad governance hides judgment behind a number.
Keep the model lighter than the decision. If administering governance takes longer than understanding the change, the governance process has become part of the problem.
Ownership Is Often the Real Decision
Many customization discussions focus on technology.
The bigger issue is usually ownership.
Before adding a field, workflow, integration, CMDB attribute, Workspace component, or custom application, ask:
- Who owns the definition?
- Who owns data quality?
- Who approves changes?
- Who funds lifecycle maintenance?
- Who retires it when it is no longer needed?
Example: The Shared Task Field
Three teams request the same new field on Task.
Most discussions immediately jump into data modeling.
The first question should be:
Who owns the concept?
Without ownership there is no reliable definition, no governance model, and no retirement strategy.
I've seen organizations spend hours debating where a field belongs and only minutes discussing who owns its meaning.
The ownership problem usually causes more damage than the technical design.
Use Governance That Scales With Impact
This is still governance.
The goal is not less governance.
The goal is governance proportional to impact.
Too many organizations apply the same review process to every change. A small local enhancement should not compete for attention with a platform-wide design decision. At the same time, apparently minor changes can sometimes have enterprise-wide consequences.
The question is not how the change is implemented. The question is how far the consequences can spread.
As impact increases, the depth of governance should increase with it.
| Level | Use When | Example & Signals | Who Decides |
|---|---|---|---|
| Level 1 Normal Delivery Review |
Use when the change is local, understood, and easy to reverse. The impact is limited to a single team, application, or user experience. |
Example: Custom Workspace validation component.
|
The delivery team should usually be able to make this decision without involving architecture boards or specialist reviewers. |
| Level 2 Architecture Review |
Use when the decision affects shared platform behavior, shared data, or long-term platform strategy. The concern is not implementation complexity. The concern is organizational reach. |
Example: Changing Universal Request state behavior used by multiple products.
|
This deserves broader review because different teams may experience the consequences even if only one team requested the change. |
| Level 3 Specialist Review |
Use when the change enters a domain with dedicated expertise, accountability, or regulatory obligations. The purpose is not additional bureaucracy. The purpose is ensuring decisions are reviewed by people who understand the risk. |
Examples:
|
Specialists should be involved because of the risk domain being affected, not because the solution happens to use customization. |
A useful rule of thumb: The more teams affected, the more shared data involved, the harder the change is to reverse, and the greater the regulatory or operational risk, the deeper the governance should be.
Four Common Outcomes
| Outcome | Meaning |
|---|---|
| Proceed | The problem is real and the design is acceptable. |
| Proceed with Conditions | The design is acceptable if specific obligations are met. |
| Redesign | The need is valid. The implementation is not. |
| Reject | The requirement itself doesn't clear the bar: insufficient value, duplicates an existing capability, or nobody will own the result. |
Redesign is not rejection.
It is often the most valuable governance outcome.
The Question Most Teams Miss
The customization debate has always asked the wrong question.
The question is not whether something is configuration, customization or custom development.
The real question is:
What problem are we solving, what consequences are we creating, and who is willing to own them?
