Skip navigation

Developer Community

1 Post authored by: Huey Kam Employee

One of the most common things that developers and support engineers encounter is troubleshooting why certain things are not working as expected. Having decent debugging tools and strategies to assist you identify the cause can be the difference between 12 hours of troubleshooting and an hour of debugging. ServiceNow offers several debugging tools that can help you determine the cause of strife.


When you enable any of the ServiceNow debugging options, it will only do work on your current browser sessions. Hence, it is safe to enable them without worrying that it might affect other users on the system.

Screen Shot 2015-05-28 at 9.45.17 AM.JPG

 

 

If you are not sure which debug to turn on, you can try the "Enable All" and get yourself familiar with the options. To end the debugging, click on the "Disable All" or logout the session.

 

5 Debugging Strategies

There are several debugging strategies that developers use. Debugging strategies that work for one developer or support engineer may not necessarily work for another. You can use a combination of debugging tools to find the best way to decipher the issue occurring on your instance.

 

Brainstorm a Hypothesis

Everyone has theories about various things. There is a saying "if you are a hammer, everything looks like a nail." One of the most common pitfalls of debugging is having the wrong assumption. From my experience, the most difficult cases are most likely caused by an innocent change that goes over looked. Hence, it is necessary to brainstorm a list of possible hypothesis and rule them out one-by-one before proceeding.

 

Rule out the hypothesis

For each hypothesis, the general approach is to design some experiments and test them out. To do this properly, it is better to stick with the same test case and avoid too much variations. The idea is to test the hypothesis without creating unnecessary variations to the problem. However, we may have a long list of hypotheses, ruling them out one-by-one may be time consuming. This is where a "Divide and Conquer" approach would save your team a lot of time.

 

Divide and Conquer

There are various way to divide hypotheses and test cases. Generally for ServiceNow, there could be two possible causes that lead to the problem:

  • A bug with a ServiceNow out-of-box feature.
  • A mistake with the customization.

 

If it is a product issue (bug), then there would not be any need to waste more time troubleshooting the issue. Isolating the case would make it easier for ServiceNow Support to help troubleshoot.

 

Isolate the case

To speed up the troubleshooting process and to help the ServiceNow Support productively, it is better to create a simple isolation case to replicate the issue. If the issue can be replicated with the simple case, you can use the steps for replication to lodge a Support incident for ServiceNow Support to investigate.

 

 

Example:

Here is an example of a problem which can could be replicated. In this case, whenever I updated the Requested Item, something weird happens. I turned on the debug and I can see something weird:

 

Screen Shot 2015-06-01 at 10.14.24 AM.JPG

 

The "==>" and "<==" signifies a "Business Rule" call. In this case, the name of the business rule is "FunnyBusinessRule".

When the "Log" is checked, we could see more information of the messages from the Business Rule "FunnyBusinessRule".

 

Screen Shot 2015-06-01 at 10.12.19 AM.JPG

 

Looking at the list of business rule, we can see that it is custom business rule created by the user "Huey" and that it was recently updated.

Screen Shot 2015-06-01 at 10.20.15 AM.JPG

 

If deactivating the business rule makes the problem go away, then we can be sure that the business rule is causing the issue. In this case, it is a customization issue and not an out-of-box issue.

 

Do a review of the business rule and try to understand why it is there in the first place. There might be a need to approach the developer/contractor who create or last updated the business rule.

 

If the issue cannot be replicated with the simple case, then there must be something else causing the issue. Either the steps to replicate are insufficient or there is a customization causing the issue. Reevaluate the hypothesis again and repeat the debugging process cycle from the beginning again.

 

Get Support involved

Having a simple isolated case is helpful not only for yourself but for anyone whom you are approaching for help. There are various places to seek clarifications regarding the features before you approach ServiceNow Support for assistance. Sharing your case in the community is a good starting point. If the community is unable to guide you to your solution, Support may be needed.

 

To help ServiceNow Support in assisting you more efficiently, some information are appreciated when reporting your issue:

  • Steps to reproduce
  • Screen Shots
  • Expected result
  • Observations (if any).
  • Affected instance/platform (if relevant)
  • Impact (how the issue is impacting your instance/company)
  • Workaround (if any)

 

Debugging is a creative and patience process, the ServiceNow debugging options are just the tools. At times, it might seem like a nightmare trying to find out "what you did last summer" or trying to find out who took away the kettle (from "Polly puts the kettle on"). Think of the whole process as a treasure hunt game and hopefully that helps.

 

For more information see

Debugging Tools Best Practices

JavaScript Debug Window

Search "debug" and related search terms on the community

ServiceNow ShareNow Portal

Hi Knowledge Base (requires Hi login)

 

Meanwhile, happy debugging

Filter Blog

By date: By tag: