While implementing ServiceNow, businesses must often grapple with the question of how to ensure that ServiceNow’s functionalities and its processes are completely in sync. It is expected that ServiceNow’s built-in functionalities may not always fit into existing business processes and workflows and some adjustments must be made to bring balance. This requires some changes to business workflows and configuring or customizing ServiceNow. With customizing a ServiceNow instance, users must evaluate and understand to what extent customization should be undertaken as it carries with it the risk of affecting the implementation. In this article, we will discuss the difference between configuration and customization of ServiceNow implementation.
Configuration in ServiceNow
ServiceNow, like many vendors, understands that clients may need the software to be flexible enough to be tailored to specific needs. With configurations, businesses can make minor modifications to existing functionalities to fit the requirements of the business without altering the baseline code. For instance, modifying form layouts, adding new fields to existing forms, adding company name and logo, changing updating or email configuration, assigning roles to groups, adding plugins, etc. can all be termed as configuration changes. In fact, configuration changes would include all changes that are made using a built-in toolset and without touching the baseline installation code.
What is Customization in ServiceNow?
Customization involves changing the ServiceNow instance’s baseline installation code to add functionality that is not already included in the software. Businesses choose customization when their existing processes and workflows are not fully compatible with the default workflows of ServiceNow and instead of changing the processes, they find modifying the functionalities of the platform a more viable option. For example, changing Client Scripts, UI Action, UI Scripts, Business Rules, or creating lookup tables by modifying code would all be considered customization.
Why Customization Can Make or Break ServiceNow Implementation
Customizing ServiceNow can bring its own set of problems and challenges as it involves going beyond the “out of the box” solution to modify the underlying code. In effect, it is making a software function slightly different than it was originally intended to function and though there may be benefits, there are also challenges such as:
Affects Upgrades
Every six months ServiceNow releases an upgrade to enhance the platform by adding new features, eliminating bugs, and addressing security issues. For configured installations, these upgrades are implemented within a few days but customized system upgrades can take months. This is a problem when a new upgrade has been released before the last upgrade has been fully implemented. Another important factor is that the upgrades may break the custom code since they were not part of the original codebase that the upgrades were released with. If the platform has been heavily customized, businesses may not be able to upgrade at all thus missing out on new features as well as bug fixes and security updates.
Need for Specialized Resources
Customization by definition means modifying the baseline code to add functionality, and this also means it would require dedicated and skilled developers to perform these changes. It naturally follows that the number of resources needed would correspond to the extent of customization. This can raise the cost significantly. Similarly, more developers would be required when implementing upgrades depending upon how customized the platform already is. If not determined at the onset, these requirements of skilled resources can increase the overall cost.
Customization Best Practices
For the reasons explained above, customizing a ServiceNow implementation should not be the first choice. Instead, businesses should explore configuring the platform to meet process requirements. But there are reasons why businesses may have no other option but to customize ServiceNow. These may include support for legacy processes that cannot be supported by configuration, regulatory or compliance purposes or is a necessity for realizing a business value objective. Businesses with legacy processes or complex workflows may want to retain these processes and workflows and choose customization.
When customizing, several factors should be top of mind, some of which are enumerated in the ServiceNow customization guide. Businesses should carefully evaluate demands for customization to ensure that there is clarity at the onset on customizations to be made. Excess customization can lead to increased cost, time, and resource requirements as well as add unnecessary complexity to the system. When implementing upgrades, care should be taken to ensure that the new code does not break the existing code. It is important to follow ServiceNow conventions while implementing customized functionalities. Keeping backups or working on cloned instances can be a great help in case the code breaks during upgrades and there is a need to roll back changes. Documenting all changes in the form of comments is key to resolving conflicts if a lot of time has passed between updates.
Conclusion
Documenting all changes in the form of comments is key to resolving conflicts if a lot of time has passed between updates. Customization can make or break ServiceNow implementations which is why it is necessary to have an experienced ServiceNow implementation partner who can understand the risks of customization and how to navigate the process. Choosing the right ServiceNow partner to work with when embarking on a customization journey can be crucial in the long run. This partner would be able to ensure there is no excess customization or best practices have been followed.
