ServiceNow Definition of Customization and Configuration

[pierrondi]

Definition of Customization and Configuration

When considering enterprise software of any type, it is important to understand the difference between configuration and customization as well personalization in the right context. The crux of the difference is complexity. Configuration uses the inherent flexibility of the enterprise software to add fields, change field names, modify drop-down lists, or add buttons. Configurations are made using powerful built-in toolsets. Customization involves code changes to create functionality that is not available through configuration.

Customization can be costly and can complicate future upgrades to the software because the code changes may not easily migrate to the new version. Wherever possible, Clients should avoid customization by using configuration to meet its goals. Clients also should understand their vendor's particular terminology with regard to this issue since words like "modifications" or "extensions" often mean different things to different vendors, such as ServiceNow.

Customization

A customization is a feature or extension or modification of a ServiceNow feature that requires custom coding and or some form of implementation outside the OOTB context.

Any changes to the out of box object is considered to be customization and in ServiceNow and different objects are used for customization;

Any new addition of the ServiceNow objects or changes to the existing ones an expected change in the functionality;

Any new addition or changes to the existing objects mentioned below is considered as customized objects;

Customization examples:

• Client Scripts
• UI Action
• UI scripts
• ACL's
• Business Rules

Questions to help mark as a customization:

1. Does may affect future upgrades?
2. Complex JavaScript needed?
3. Maintenance requires experienced developers?

Configuration

A configuration is where we use native ServiceNow capabilities and tools in the system to change its behavior or features to address business needs.

Any change to the configurable data which changes the functionality of the application is considered as a configuration change.

Any configuration should be a data-driven change and should be easy to revert back without any changes to the ServiceNow code base.

Configuration examples:

• Groups
• Support Groups
• Assignment rules
• Preferences within ServiceNow
• Notification / Email configurations

Personalization

Another advancement that has really changed is "Personalization".   It used to be that you only allowed people to change their list view.   Now they can change the form too, make reports, adjust their notification preferences, add themes, change how fields look, and all kinds of other features.   This "user enablement" along with Self Service, Service Catalog, and Knowledge Management have instilled a "DIY" approach to issue resolution at many companies.

Any change made to ServiceNow system and it applies only to the user changed is considered as personalization.

Personalization will not have any impact on both configuration and customization.

It's more of the personalized settings within ServiceNow for the user similar to the User Preferences.

Personalization examples:

• Themes
• Lists
• Accessibility and Themes
• UI Look and Functionality
• Date Time Look, Time zone, and Format
• Form Fields, Tabbed Forms, Related List Loading
• Favorites and Tagged Records

Conclusion

The lines between configuration, personalization, and customization will blur even more as in the future as applications become easier to customize.   What is important is how difficult it is to make that configuration/personalization or customization and how it will affect the clients with maintenance and upgrades as well the ability to grow and scale our services.

[Corey19]

Hi guys,

My personal opinion is, as ServiceNow decide what they support, it's best to seek their advice for any clarification on what is supported and what is not, which is the crux of the Config vs Customisation discussion.

In terms of adding new fields being disputed between the OP and the ServiceNow rep, I can attest to them being customisation, as having inherited a very old build we've discussed this very thing with ServiceNow support after they had changed table relationships for the CMDB.

I've seen using customisation described elsewhere as something that should be assessed on risk and I completely agree. In this particular case you could look at a new custom field as:

- This is a plain text entry field with no dependency therefore has minimal risk of breaking in an upgrade or;

- This is a field tied to a reference field that is referencing another table, it's moderately possible this might break in an upgrade if the vendor decides it needs to make changes at a database level therefore it is a medium-high risk.

Obvioulsy this is oversimplifying a little but does show the point.

Cheers,

Corey