[Music] please subscribe to my channel and click on the bell icon to get the regular updates of my channel and do not forget to like comment and share hello everyone welcome back to sas with servicenow this is our second video of my new series talk now lot of people have questions about baseline system in servicenow and customization so in this video i will be talking about three things the first one is what is baseline and what is customization in servicenow and what exactly the difference between both of them the next thing will be what is a configuration in service now and what is a customization in service now and the third thing would be what are the best practices you need to follow to perform customizations in servicenow platform so let's start with the first topic that is what is baseline in servicenow and what is service down what exactly the difference between them now what is baseline first now anything any feature any scripting element you get directly from service now is basically called as baseline system so when you get different modules and service now like incident management change management problem management other applications like security vulnerability response maybe configuration compliance may be security incident response or any out of the box application you get even it's a user module even it's a group module even it's a roles module all these elements which you get directly from servicenow and whatever elements scripting elements they have like we have we have lot of elements like business rules client scripts ui pages ui scripts all these different ui policies data policies so whenever you enable these modules or you when you get the new instance service now already has those different records that means type of different business rules type of different client scripts so when you directly get those things from service now in the instance that becomes a baseline that means if you're getting a client script which is already there in the instance and you have not touched that basically module yet then you can say that's basically the baseline client script because you have not done any kind of editing any kind of change to that client script or business rule so that is basically the baseline system baseline element of service now now what is a customization then now when you touch when you do any kind of editing any kind of change to these different elements i'm talking about the baseline elements like business rules client script so if we have any out of the box client script maybe let's say for incident management for incident form and if i am going to change that client script which is already there in the system directly from servicenow that will become customization even it's a business rule which doesn't have any script but it is out of the box it is a baseline business rule even i'm not doing scripting so customization does not mean just scripting customization is something if you are changing the baseline even that business tool doesn't have any script just those configurations like you select different conditions and and actions and if you are touching that that will also be called as customization because you are touching the baseline element of the platform so that is the difference between baseline elements baseline system of service now and customization now i will talk about configuration and customization so what exactly the difference between because a lot of people uh do changes in servicenow platform and we have to because every organization has their own needs they have to configure the platform or customize the platform as per their requirement they cannot go directly as per the standard what we are getting from service noise instance or service now because every organization has their own process controls procedures so organizations have to change the platform but the point here is that what will be called as configuration and then what will be called as customization so i will i will try to explain this with the basic tables we have like incident we already have incident form directly out of the box you can create the incident where a lot of fields are also non-mandatory but if i talk about lot of organizations they also make them mandatory if i give example of configuration item configuration item is not mandatory on out of the box incident form but a lot of organizations we definitely change it so that's a difference because people that means they have made it mandatory they have done some customization and i would say it is definitely needed but the point is what will be called as configuration what will be called as customization so let's say we have incident form and you have couple of fields on incident form which comes out of the box but you want to add a new field on that form so if you will add that means you will change the form layout and if you will add that field on the form that will not be called as customization that will be called as configuration but now what will be called as customization so now if i am creating a new field and maybe i am using some kind of a logic maybe i am adding a new business rule or maybe i am adding uh i'm changing the baseline system baseline business tool then it will be called as customization because now i'm not using what i got directly from servicenow i'm going to change that i will maybe add few more fields i will write maybe a lot of other scripting elements maybe business tools client scripts ui policy then you cannot say that incident management is baseline no not at all because now you have done the customization it will be called as custom incident management which you have basically performed in your organization so that's a difference between configuration and customization even in configuration you can do a lot of other configurations like changing the branding uh changing the color changing the themes all these things definitely not be considered as customization because these are all different configurations even the property changes if you change the properties and that's what i would say the usage of properties servicenow has introduced because you can uh if you have to change the behavior of the platform and that is also without doing any kind of coding or any kind of uh writing any uh scripting element you can just change that behavior and that's the reason servicenow has created all different properties and lot of properties are out of the box but that will definitely not be called as customization because servers now themselves saying and they have created those properties that hey you if you want to change something like different you can just update the property and change the behavior so that will definitely not be called as customization but as i said if you are changing the baseline let's say you're also creating new scoped application again that is a customization you cannot say it's it's not a customization now customization can also be categorized into heavy customization and light customization now what will be the heavy customization now heavy customization would be like let's say you have incident management module an incident management module you have out of the box is business rules client scripts and other elements now on top of those different elements you are adding new fields you are adding new client scripts edit editing the existing client script changing the business rules client scripts ui pages adding more fields adding more data policies ui policies then you can call that incident management module is heavily customized but what about low basically light customization so light customization would be so let's say same thing incident module you have out of the box elements but let's say you are just adding a new business rule for performing one action maybe you are changing the layout i think layout as we definitely mentioned it is not customization you can consider it as a configuration but let's say you are adding a new business rule in that case it is a customization but it will not impact the upgrade of the platform majorly the upgrade of your incident management module if servicenow will upgrade new features with a new version of the platform and if they are going to edit or maybe they're going to change the existing business rules client scripts or different elements then it will be able to update it upgrade it properly without any issue and you will not you'll not be you'll be able to get uh new features in the platform and uh you will not miss any feature and then you can also judge whether that particular business rule is needed or not because it might happen that servicenow can come with the same feature which you have already implemented you can just disable that business rule and you are done these kind of customizations are light customizations which definitely makes the uh platform more stable rather than heavy customization which will impact the upgrade of the platform and stability of the platform as well now the question is whether we should do customization or not now answer for this question is no but the reality of all the organizations where they manage their service now instance i don't think they they do not do any kind of customization because customization i would say it's kind of not mandatory but it's kind of a need for different organizations and i told you in the beginning because every organization has their own process on controls on procedures they have to basically set up the instance servicenow instance in such a way so that it follows the process and controls they have and that's the reason different organizations have to perform customizations but even if you are doing the customization are you following the right way to do customization are you making sure that some elements are considered so that your your platform is still stable even after customization that is the most important thing here and that's our third section that what are the basically best practices you should follow while performing customization in servicenow instance so you might be getting the requirements from your customers now when you get the requirement from a customer and let's say you you you got the requirement and then you have to do uh some customization you have to touch the baseline business rule maybe you have to change the baseline client script now before accepting the requirement and starting the development i think the best thing would be the first step should be that you should reach out to your stakeholder or customer and ask that why exactly they need that requirement to be implemented if you will not implement what kind of impact they would get this question is really important because you have to tell them that if i will perform this change i will perform implement this feature i have to change the baseline which might impact the upgrade of the platform as well and they might not get the new features for that particular module if you will explain them i'm sure they will understand and that's how they will prioritize or give the urgency to those kind of requirements and they will tag whether it is must-have it is maybe it just uh it's just a normal requirement if let's say and if it's a must-have let's say they come the no they definitely need this requirement to be implemented in the platform that's that's the first thing you have already done you are done with the question uh and and the conversation you wanted to have with your customer or stakeholder that why exactly they need it but now let's say you have to do this customization so in that case you have to make sure that you you are not touching the baseline element and even if you if you are touching it let's say you have to edit any existing business rule you have to customize in such a way so that you can still revert it so let's say in the future if you will get the similar kind of requirement maybe servicenow will upgrade the feature you can at least revert it to out of the box and maybe then on top of that you can uh perform the changes to get those new features so your strategy will be really i think you have to plan different implementations development strategy so that you're following the right architecture best practices so that you're not ruining uh the features or you're not running the module so that it cannot have the upgraded features which you get from servers now directly while doing the upgrade another best practice is to create new scoped application so if you are getting a requirement rather than trying to edit your existing modules out of the box modules you should always go for scoped application which will minimize the risk of upgrade of the platform that is really important in this kind of case so if you are doing customization or you have to do customization you can definitely go for scoped application now when you again got the requirement another best practice would be you should go for low code or no code uh capabilities you have in the platform like flow designer now floor designer is one of the feature you have on the platform where you don't have to do any kind of customization that is like you can do customization but that is also out of the box because you don't have to write any script and even if let's say you change business rules i think if you will heavily add script that definitely will will be really uh hard to uh revert it to out of the box but if you will just do the configuration like you create business rules you edit business rules but just not the scripting part you just do the changes in the uh when an action action section then then it can be definitely manageable or as i said you can just go for low code no code where you can go for flow designer whatever customization whatever requirement you have got use flow designer so that it gives less impact to the platform another best practice is that you should always document all of the customizations you are doing just to make sure that you're not missing any element so even if somebody has to revert to out of the box they can at least know what kind of changes why you are making those changes in the platform why you have added that script or what if even if you are changing a baseline script why you have changed that you have you should write in the code comment as well so that another developer can come to know or even you can come to know maybe after one year you have to revert to out of the box then at least you can check that why this particular code was added but that is really important as well now next best practices i think you should always go for automation testing so even if you are doing customization make sure you are doing the proper testing you have proper automation testing test cases in atf so that and why exactly you want that let's say you are upgrading the platform so you are upgrading the platform from one version to another version once you are done you run your atf you run that particular suite for that module then you check whether you got any issues or not at that point of time you can say my upgrade is successful that means even we got the new requirement but nothing got broken we and as i said you might not get all the features for that you definitely have to review the update set the skipped update sets but at least your system is not broken because of the upgrade and that is one of the best practice because if you have done the customization automation testing is very important now these are the things about customization and baseline system and i hope this will help you to think next time whether you should do customization or not and if somebody will ask you that what is the difference between baseline system in-service and customization and what is heavy customization what is light customization in the platform thank you for watching this video and have a great day