Customization vs. configuration

The definition of what is a customization versus what is just a configuration is widely debated by ServiceNow practitioners and the industry at large. Let me clear my thoughts on it before we move further.

Software platform vendors tend to consider most of their clients’ changes as configurations of their mighty out-of-box functionality but when you contact their support helpdesk for help with something that you have changed in your instance you will often be told that your change is considered custom development and thus they cannot help you with it.

So, configurations can be defined as changes in your ServiceNow instance that are made using options built into the ServiceNow user interface for which you can normally get support from ServiceNow’s HI helpdesk. When the change/configuration does not work as expected and it’s reproducible, it may be filed as a platform bug in ServiceNow.

Examples of such supported-for-free configurations may include the creation of a new Access control rule, a new Workflow using the Workflow engine, layout re-arrangement of fields, or the creation of new fields.

A customization is when you modify code, or add new one. Changes to the code of inbound email actions, new Client scripts, or Business rules that have code in them are all examples of customizations. ServiceNow HI will normally shun away from debugging your code. If it involves scripting, it’s a customization.

The good new is that with every new release of ServiceNow the list of configurations directly supported by the ServiceNow’s user interface expands. Many of the things that required scripting in earlier versions can now be achieved with configuration. New releases also introduce new out-of-box features which you had to previously develop as customization in your instance.

But also the options for customization and development have increased. In fact in 2015 ServiceNow introduced a slew of tools to help developers better manage their code, while the Istanbul release introduces automated testing .

Why companies customize

Out-of-box functionality is great; you already paid for it and should use it as often as possible. However, most of the time organizations need to customize because of their unique circumstances.

In theory, you could force your service desk and organization to run with ServiceNow as is, but it’s much easier to mold ServiceNow to run as suits your organization and circumstances than to coerce your organization to fit into a square hole.

As Randy Mott, chief information officer at General Motors, puts it: “companies that win in their industries are the ones that figure out how to get ahead, because getting competitive advantage takes innovation, it takes creativity, and you're not going to get that from someone who's going to make everyone on the planet even."

When it comes to ServiceNow it may be sold to management on how much there is already OOB and how little configuration will be needed to meet most of the business needs, while technical folks will be invited to participate in hacking hijinks at conferences such as the CreatorCon .

It depends on your interest. Software developers tend to prefer customizing the system to perform as they specify. They take pride in their code and are sometimes accused of avoiding already existing solutions only because they were made by others (this is known as the “not invented here” syndrome ).

Business people on the other hand are less interested in new technical challenges and tend to prefer ready-made solutions that can be contracted at a predictable expense and are guaranteed by reputable vendors. Many of them, acknowledge from experience however that off-the-shelf software alone is rarely sufficient to get their business going, and so they need to have some expertise in-house.

What are those customizations that we are talking about so much?

Here are three examples of the kind of customizations. You will also find more examples of customizations that ServiceNow customers typically make in Chapter 11, and even more documented online.

Many organizations like Harvard University, Berkeley, CERN, and Fermilab research centers have made some of their ServiceNow internal release notes publicly available.²,³,⁴

1. Workflow automation

All automatic behavior and values settings defined in ServiceNow can be categorized as workflow automation. The goal of workflow automations is to streamline the execution of known processes, guide users throughout it, and reduce manual steps and the chances of human error and forgetfulness.

Examples of such automations include automating the assignment of tickets based on criteria like the email address the issue was reported to, the location of the caller, or the product (Configuration item) the support request is for. A more detailed discussion of assignment logic is in Chapter 11.

Approval requests can be automatically sent based on whom the request is for and fulfillment tasks can be automatically generated and assigned based on a predefined workflow set for the requested item. For example, the termination of an employee’s services could simultaneously trigger multiple tasks for the different teams responsible for the deactivation of the services the employee had.

For routine back-end workflows, you can define a workflow of actions and approvals that need to be taken in sequence to decommission a server for example (Figure 8-1).

Figure 8-1. Sequence of automatically created tasks triggered by a workflow

2. Convenience and cosmetic customizations

When examined critically, many of the customizations we made at Al Jazeera were in theory unnecessary. But in practice our stakeholders found them critical for their smooth operations .

For example, prior to ServiceNow the service desk was used to receive incoming emails in a shared inbox and as the emails arrived, available agents would glance at the email and flag it to indicate that they were on it. Seeing the email flagged, other colleagues also looking at the inbox will divert their attention to other unclaimed emails (Figure 8-2).

Figure 8-2. Flags in Outlook

But when tickets started pouring in ServiceNow, there were no flags for tickets and so the agents found themselves claiming the same tickets in the queue and sometimes overwriting each others’ messages and assignments.

An agent would open a ticket while another agent also had the same ticket open. Each would assign and make changes to the ticket, but would not know of other updates until after she posted her updates to the ticket.

I proposed solutions like having agents quickly assign tickets to themselves directly from the list view of tickets, or asking agents to shout the ticket they just claimed but none were deemed appropriate (Figure 8-3).

Figure 8-3. If you right-click on a ticket in a list, you can quickly assign it to yourself with one more click.

So in the end we introduced a customization that suited our service desk⁵: As soon as you open a ticket, you will be informed if someone else has also been on the ticket recently. Also, when you click to save your changes to a ticket you will be informed if someone else made new changes in the meantime, and you will be given the option to hold your changes.

In ServiceNow’s newest User Interface (UI16) a similar feature has been introduced showing you who else is also viewing the ticket at the same time as you. So after upgrading to the Helsinki release our stakeholders found the new User presence functionality satisfactory, and so we removed our customization (Figure 8-4).

Figure 8-4. The new presence feature in ServiceNow shows you how many people are currently looking at the ticket that you are also viewing

You can bet that many of the things your stakeholders want will not (yet) be in ServiceNow in a suitable fashion, and so you will have to implement them as customizations .

For another example, we also removed the impact and urgency fields from ticket forms, giving ITIL users direct control over the priority and tying each priority to an SLA. The priority itself was renamed to include the number of SLA hours associated with this priority (Figure 8-5).

Figure 8-5. When creating a new Incident ITIL users have to manually set the priority. A P2 priority has a 10-hours SLA

We also customized the look and feel of email notifications (discussed in Chapter 5) as well as which fields show up in user and ticket preview windows.

Customization process

For building “quality applications” on the ServiceNow platform, ServiceNow recommends the following development process:⁶

1. 1. Define business requirements.

2. 2. Define what information the application needs to track.

3. 3. Build the application.

4. 4. Test the application.

5. 5. Share the application on the ServiceNow Store.

Even if you are not developing a fully-fledged application on ServiceNow, you will benefit by adhering to a development process that above all sets the expectations for your stakeholders and then delivers on them in a predicable fashion.

In essence, your stakeholders need to have clear and consistent answers to the following questions about the way customizations and changes are made to the instance:

1. 1. How are customization requests reported and tracked?

Stakeholders can chat with you about their feature requests or bugs. But then what happens with their requests? How can they follow up on them? How do they know if and when they will be released?

An Excel spreadsheet or initial requirements document may be fine as a starting point but often there will need to be a discussion between developers, analysts, stakeholders, and testers for each new feature before the final outcome is ready. Where will you track all this?

1. 2. Where will customizations be developed?

2. 3. How do you deploy customizations?

Especially for an enterprise platform like ServiceNow on which stakeholders rely to perform their work daily, stakeholders will be anxious if you make unannounced changes on the instance while they are also using it.

As the manager of the application you want to give them the confidence that developments are made on another instance and not on the production instance, while deployments to the production instance are controlled by an open process that involves stakeholders in testing and notification.

At Al Jazeera developments are made in a non-production instance and are packaged together for deployment to the production instance at a time agreed upon by the stakeholders.

Stakeholders are also typically given a window of three days to preview and test the latest developments in the Test instance so they can report on issues they may identify before deployment to the live instance (Figure 8-6).

Figure 8-6. Customizations lifecycle

The objectives of the development process are to:

1. 1. maximize the stability of your ServiceNow production instance through a strict development-test-release process;

2. 2. set standards to ensure new customizations don’t result in inconsistent interfaces that confuse users;

3. 3. grant people access roles suitable for their day-to-day activities, but curb the chance of accidental mischief on your production environment;

4. 4. in case of issues with your instance, ensure you can recover quickly;

5. 5. maintain a non-production replica of your ServiceNow environment for development and testing;

6. 6. avoid customizations that will make maintenance and upgrades of your ServiceNow instance difficult;

7. 7. flexibly on-board new teams in ServiceNow without affecting present users of the system or requiring further customization .

Requirements backlog

Requirements will be coming at you from meetings with stakeholders, emails, and your own observations. It’s important that you then store all of them in one place that is central and shared with your stakeholders, and that is flexible enough to keep track of related conversations and updates.

In the spirit of eating your own dog food, I recommend you track all issues and enhancement requests for your ServiceNow instance in your ServiceNow instance itself.

This is a common practice in the IT industry and it has been cited from big name companies such as Microsoft, Apple, Google, and YouTube. In 1980 the president of Apple Computers famously wrote a memo announcing:

“Effective Immediately!! No more typewriters are to be purchased, leased etc., etc. … We believe the typewriter is obsolete. Let's prove it inside before we try and convince our customers.”⁷

By the same token, using your own ServiceNow instance will give you and your ServiceNow developers and administrators a direct first-hand experience of managing tickets in ServiceNow both from a user perspective as well as from a resolvers’ perspective. Ideally, your external partners should also use ServiceNow, as discussed in Chapter 3.

Development and testing

Poorly designed customizations can lead to unexpected side effects in unexpected areas of the application, need rework, and offer an inconsistent user experience. In short, your ServiceNow instance can become a mess!

The responsibility for designing good solutions falls on your ServiceNow developers, but this often also requires understanding and collaboration from the client too.

As the manager of the application, you can set the expectation for both business users with requirements (yourself included) and developers for the kind of customizations you allow on the platform, and those that you reject (even if possible) in favor of simpler solutions coherent with the overall design in ServiceNow.

A wonderful example of management that understands the simplicity principle comes from a 2006 interview with Steve Jobs.

Steve Jobs was asked about Microsoft’s new iPod competitor and its community-building feature. Steve Jobs dismissed it by noting how unnecessarily complicated it was:¹²

“I’ve seen the demonstrations on the Internet about how you can find another person using a Zune and give them a song they can play three times. It takes forever. By the time you’ve gone through all that, the girl’s got up and left!”

“You’re much better off to take one of your earbuds out and put it in her ear. Then you’re connected with about two feet of headphone cable.”

The same logic reasoned by Steve Jobs can be applied to ServiceNow requirements. For example, a common issue fretted about when introducing ServiceNow to your department is which categories and sub-categories there should be.

The categories the service desk wants will undoubtedly not be the same categories the network team wants, and the same is likely to be true for each team because each team deals with different issues and has a particular world view.

In this context the please-all requirement may come as:

Show different categories based on which team the ticket is assigned to.

But this is a convoluted solution and requires twisting ServiceNow’s categories by adding new tables and team-based access constraints. Why go this way?

Rather than forcing a solution on ServiceNow, it would be better to identify a solution that works with the ServiceNow default way.

A much simpler solution for example (and one that requires no coding) is to add all category options with a designated team prefix for ease of reference.

For example, categories of the service desk can be prefixed with the “SD” prefix as in “SD: Access,” while Network team categories with the “NET” prefix as in “NET: Connectivity .”

This way all teams have their categories, each team can easily find their categories and no convoluted ServiceNow configuration and development is required. Additionally, you could also use the category field to identify the team whose categories you want to preview in the subcategory field only.

You get the idea; encourage creative yet simple solutions to the requirements proposed by your stakeholders (Figure 8-7).

Figure 8-7. Incident subcategory used to list the Network's team categories

Other subcategories would be shown if the Category selected was Service desk (Figure 8-8).

Figure 8-8. Incident category drop-down with team-based categories prefixed with a prefix for each team for ease of identification and navigation

Consistent standards

As new feature requests come in and changes are made, your instance behavior can become unpredictable and confusing.

A principle of good application design is to minimize the thinking process your users have to go through using your application, making sure things tend to be where they expect them across the application. Applied to ServiceNow, here are some standards I recommend you adhere to when planning new changes:

1. Minimize the number of buttons on forms

As per good user interaction practice, your screen should have a very limited number of call-to-action buttons (ideally, only one).

For this, rather than add new buttons to your forms, add new options in the Context menu accessible by right-clicking the ticket header (Figure 8-10). The buttons displayed on the form should be only the most common two or three actions you expect users to take on the ticket in its current state (Figure 8-9).

Figure 8-9. Unhold updates the ticket and resets the state to Work in progress.

Figure 8-10. The context menu accessible by right-clicking a ticket header provides additional options.

Hold updates the ticket but keeps it on hold (Figure 8-10).

2. Human message with every email

It’s common for users to overlook email notifications received from a website or ticketing system, because many of them are computer-generated.

It is better if you set the standard for ServiceNow notifications to be only triggered with a message typed in by somebody. Once users notice that, they will be more likely to take your emails seriously and you eliminate the risk of ServiceNow inadvertently spamming your organization with computer-generated emails.

To ensure this, you would mandate that closing a ticket or putting it on hold would require the person changing the ticket status to also write a human-readable comment to the caller. Such requirements will trigger them to think more carefully about the change.

3. Limit team-specific customizations

As illustrated with categories, it is very likely that every team using ServiceNow will delight in giving you custom changes specific to their team.

They will want different notifications to be sent, different names for fields on the form, and even a different layout for the same fields.

As of the Istanbul release, ServiceNow is not built for having a different incident form for each team; it can be done creating team-specific access roles and rules, new tables or new views.

But it can grow messy and become difficult to manage. If you can, it would be better to limit team-specific customizations and ensure the layout and behavior of ticket forms shared by multiple teams be consistent for all users.

4. Transparent behavior

What happens If I write a comment? Who will be notified? Will an email be sent if I close the ticket without writing a comment? Once I submit a request, to whom will the approval request be sent?

¹³ Here is an illustrative example of the sort of questions and confusion that non-transparent behavior raises in the mind of its users. As published by Harvard University IT on its website, a user asked:

I have a question about “watcher” notifications in ServiceNow. Someone else added me (and a few others) as a watcher to this ticket INC00882705 and made work note updates four times since May. We only today received a notification email that the work notes had been updated-she closed the ticket and stated we hadn’t gotten back to her. Can you explain when watcher notification emails are and aren’t sent out for a ticket? In this case, the person who was updating the work notes thought that we were getting notified but in fact we were not and so the ticket went unnoticed.

I’ve asked the user to assign tickets to our queue instead of adding us as watchers, but it would be nice to know when watcher notifications will/won’t be sent out.

Users of your system will be wondering about these questions as they use ServiceNow and it is not the feature of a good system if users feel puzzled or out of control.

For this, when you make new backed-end customizations remember to also to show information messages in context that make obvious the new unexpected behavior of the customization (Figure 8-11).

Figure 8-11. When viewing a ticket that is on hold, an information banner informs that the ticket will be automatically closed if not updated within a set number of days.

Also, whenever possible try to make things visible directly in front of the user. For example, if approval will be collected from her line manager, make that obvious in the request form and copy her in the CC of the approval request so that she can chase her manager to approve.

Development instance

ServiceNow is a flexible application and many things in it can be configured without coding. But whether coding or not, not all changes are equal.

A change to inbound email actions or the addition of one email notification may sabotage your instance processing of incoming support emails, or spam them with unexpected email notifications. A few events in which customer emails were missed are sufficient to erode trust in the application and lead to escalation to senior management.

For this, it’s important to guard your production instance from uncontrolled changes to functionality shared by many users. It’s better to make changes and test them in a non-production instance first, and then deploy them to the production instance in a controlled fashion.

Your license contract with ServiceNow normally provides you with two ServiceNow instances: one production instance and one non-production instance. The non-production instance is provided to you for development and testing.

You should strive to maintain both instances identical in terms of configuration and customizations, with all developments being done in the non-production instance first and then transferred to the production instance.

Occasionally, you will also want to clone your production instance onto the non-production instance to make sure they are in sync (Figure 8-12).

Figure 8-12. Release developments from your non-production instance to your production instance

In ServiceNow changes are tracked and packaged in so-called Update sets (Figure 8-13). Developers export Update sets from the development instance and import them into the Production instance to apply all the developed changes at once.

Figure 8-13. Multiple update sets may be associated with the same release

Release and deployment

Imposing the discipline of developing in a non-production instance first does not have to be associated with delayed releases in production. Facebook, probably the most heavily used software platform in the world, releases new developments to Facebook.com twice a day.

The keys to frequent and stable releases are:

• Release in small chunks. Don’t wait long before you release; try to always break down projects and features in a series of small, and thus relatively safe, releases.

• Involve your stakeholders. Even though your developers may be confident of the features developed, you want your customers to test and confirm they are indeed as they wanted before you release.

This is of paramount importance in managing expectations because it will give your stakeholders a sense of control over their working environment in ServiceNow, but also in the event that bugs show up they will be much more understanding because when they tested they could not detect them.

Please note that user testing here is not meant to be an alternative to developer testing; you should ask customers to test only once developers are confident from their side that the features work.

Finally, after the release you may want to meet with stakeholders again in order to:

1. 1. get their feedback on issues discovered after release;

2. 2. prioritize developments for the next release.

For your convenience, Appendix A also lists checklists to help you assess the complexity of your customizations and remind you of steps to take before and after release .

Tweet-ready takeaways

• If ServiceNow HI support helps troubleshoot and fix your SN change, then it's a configuration. Otherwise, it's a customization.

• It is easier to mold ServiceNow to run as suits your circumstances than to coerce your organization as suits OOB. This is why you customize.

• Eat your own dog food and track all issues and enhancement requests for your ServiceNow instance in the instance itself.

• “Ordinary people should be able to create meaningful applications for their organizations”—Fred Luddy

• Those who invest labor in making something consider it much more valuable than if it were done by others. Employ stakeholders.