FUD Alert: Service-now.com requires javascript coding

Competitors are getting very creative when attempting to limit the damages of the Service-now.com tsunami. Some of them use some FUD to stop the “Service-now.com peril”. That’s the case of a French ITSM tool competitor and one or two other legacy ITSM tool vendors who are running as quickly as possible away from their customizable platform and pushing customers to accept a one-size-fits-all, out-of-the-box ITIL approach.

It seems the marketing team of this particular French vendor decided to address the threat of Service-now.com by focusing their key messages around “Codeless SaaS application” and spamming the Linkedin community with very serious polls attempting to show that what customers hate most is tool customization. Then they tweeted that customers preferred their solution to Service-now.com because it did not require javascript coding.

Why is the marketing team spending this energy on creating this FUD? Have they done their homework before using this argument of Service-now.com requiring javascript coding? Their solution is a good solution, why are they trying to fool their customers and prospects with this message?

In any case, the best way to address FUD is to fight back with facts, only facts. The fact is that most of the configuration of Service-now.com can be done with no code. Pure (and easy) configuration and parameters.

Let’s take a use case. Let’s imagine that a customer needs to personalize the way Incident Management works.

The requirements are:

  1. Remove impact and urgency fields because these concepts are not used in their service desk
  2. Change the data dictionary of the Priority field that is currently read-only to editable
  3. Create a new field “Cause code” (choice list)
  4. Three values should be entered in this field. The 1st value should be shown in red when selected.
  5. Make the new field “cause code” mandatory when the incident is resolved or closed.
  6. Change the position of the button “Create Problem” that is currently available as a right-click button

Here is a quick screencast showing how to perform this configuration:

 

So, if we summarize: addressing this use case required zero code, no specific skills, and was completed in 5 minutes.. Wow not bad! This use case demonstrated very well that most of the requirements of a typical IT organization can be addressed in a very efficient way in Service-now.com with no particular coding skills.

But then, where does this stuff around “Service-now.com requires javascript code” come from? Well, that’s because it’s true! But it is only rarely used. The thing is most big organizations don’t want ” Out-Of-The-Box.” They have complex requirements that no configuration feature can address and this is when the javascript comes into the game and enables the most flexible tool in the market! This is what competitors don’t get: when they say “no, we can’t do that, our tool doesn’t allow it or it will require development” we simply say: “Sure, we can do that”.

Let’s get back to a use case: let’s imagine that the customer wants to change the way a Problem record automatically closes the related incidents. The requirement would be to modify the behavior so that closing a Problem would mark the related incidents as “resolved” and automatically select the value 3 in the field “Cause Code” (you remember, the one we just created in the previous case). For that, the administrator would simply go to the business rule “Close related incidents” and change 2 lines: one line to select the Incident state “Resolved” instead of “Closed” (for that, simply change the value) and then add a line of code to mention that the rule should also automatically select the value 3 in the “Cause Code” field. Done.

It is important to understand the difference between javascript and development. When you are doing javascript in Service-now.com, you are not performing core system development. You are simply taking benefit of well structured components, such as client scripts, business rules and UI actions to actually go beyond configuration. And the beauty of all this is that this code gets along very well with the configuration features and last but not least, your coding will be fully preserved in the next release!

Service-now.com is therefore codeless for most of customers’ requirements. The difference comes when most vendors cannot address very specific needs, Service-now.com simply says “Yes, we can do it”.

PS: I used zero code to write this post..

Michel R.

PS: here are the configuration steps in case you want to reproduce them directly in https://demo.service-now.com/

1st requirement: go in the incident form, right-click on the header, select “Personalize > Form Layout. A slush bucket is displayed. The left side includes all available attributes. The right side shows the fields currently displayed in the Incident form. To remove the impact and urgency, select the 2 fields and click on the left arrow. That’s it. No code required.

2nd requirement: To modify the dictionary of the field, simply right-click on the field label, select “Personalize Dictionary”. In the screen, you will find that the flag “Read-only” is marked to TRUE. Simply uncheck. Done. No code required.

3rd requirement: again, go back to Personalize > Form layout. At the bottom of this screen, you will find a section to create a new field. Enter the field name “Cause code” and select the type “Choice list”. Clicking on “Add” will automatically add the field in the right side of slush bucket. Move the new field to the appropriate position and click Save. Done. No code required.

4th requirement: Go to the newly created “Cause Code” field. Right-click on the label and select “Personalize choices”. You access a new slush bucket where you will be able to create the 4 values just as you did for the creation of the new field. Enter the 4 values. Done. no code req..(well, you get my point). For the red color when value 1 is selected, right-click on the field label and select “Personalize Styles”, create one style for the value 1 (e.g. color: tomato). Yeah, one more requirement done.. with no code.

5th requirement: Right-click on the incident header, personalize > UI policy. Create a new UI policy. Give it a name and description (e.g. Cause Code mandatory when Resolved or Closed”. In the conditions, simply select “Incident State is Resolved OR Closed). Save. Then create the UI policy action: select the “Cause Code” field and mark it as Mandatory = TRUE and visible = TRUE. That’s it. This field will now only appear in the form when the user selects the incident state resolved or closed. And it will be mandatory only at this time. One more requirement addressed in a simple way with no code! Yeah!

6th requirement: Right-click on the Incident header, select Personalize > UI Action (a button in Service-now.com is called a UI Action). Select in the list the button to be changed (in that case “Create Problem”). Then, select the position you would like to see the button appear (for instance “form button” that will display it in the main form). That’s it! NO CODE!

mm
Michel is one of the co-founders of Aspediens (acquired by Fruition Partners in 2016) and now CEO, Europe at Fruition Partners. As a serial entrepreneur with strong experience in innovation, product management and solution delivery, he spots trends and writes about the future of Service Management.
Recent Posts

Start typing and press Enter to search