safe way to deactivate/edit OOB Business rules, client scripts to let them not applicable for our tables

Bhavana Reddy
Mega Guru

Hello Guys,

In our System we have some OOB Business rules which runs on the parent table but we do not want this business rule to run in our Child tables and what is the best suggestion you can provide to us inorder to not let this OOB Business rule run on our Child tables

approach 1: Shall i modify the OOB Business rule and exclude my child table

approach 2: Deactivate the OOB Business rule and create the Custom BR and add the condition to exclude the Child table

 

Guys please suggest me what is the best approach as it should not cause any problems in the future upgrade

1 ACCEPTED SOLUTION

Hi Bhavana,

Surely, so yes you will have a problem during upgrade and that's actually a best practice. What really would happen is since you have modified the OOTB business rule and if there is a change in the code for this BR in future upgrades by ServiceNow, the record will have a conflict kind of stating 'A new version of this code is available' and would come up on skipped logs during upgrade.

 

Now what you would do during upgrade is to compare the code which has come through on the upgrade and what you have currently, if there are certain lines of new code added as a new functionality by ServiceNow then you can either merge it with you current code changes, or skip the code based on your requirements. You can read a bit more here -

https://docs.servicenow.com/en-US/bundle/sandiego-platform-administration/page/administer/platform-upgrades/task/upgrademon-process-skip-list.html

Why this is considered as a best practice is you don't miss out on any new functionality ServiceNow has brought, if you have a chnaged code toh will get to decide if you want to merge the new changes into your modified BR. You wouldn't know if you create a new BR since they wouldn't come up in skipped logs. 

Hope the answer helps, happy to explain more if you have further questions. 

Thanks, Harneet

View solution in original post

9 REPLIES 9

Hi Harneet,

 

Thank you for your response, suppose if i go with the approach 1 then it will cause issue during upgrade right as we are modifying the OOB Business rule

How to deal with that scenarios? if possible please help me to understand as i have moderate knowledge in servicenow

Hi Bhavana,

Surely, so yes you will have a problem during upgrade and that's actually a best practice. What really would happen is since you have modified the OOTB business rule and if there is a change in the code for this BR in future upgrades by ServiceNow, the record will have a conflict kind of stating 'A new version of this code is available' and would come up on skipped logs during upgrade.

 

Now what you would do during upgrade is to compare the code which has come through on the upgrade and what you have currently, if there are certain lines of new code added as a new functionality by ServiceNow then you can either merge it with you current code changes, or skip the code based on your requirements. You can read a bit more here -

https://docs.servicenow.com/en-US/bundle/sandiego-platform-administration/page/administer/platform-upgrades/task/upgrademon-process-skip-list.html

Why this is considered as a best practice is you don't miss out on any new functionality ServiceNow has brought, if you have a chnaged code toh will get to decide if you want to merge the new changes into your modified BR. You wouldn't know if you create a new BR since they wouldn't come up in skipped logs. 

Hope the answer helps, happy to explain more if you have further questions. 

Thanks, Harneet

Thank you so much 🙂

Hi Harneet,

Currently what we have done is ..

 

approach 3: Instead of editing the OOB Business rule, we have created the Custom BR by overriding the OOB Business rule ( when we override the OOB BR it will be skipped during the upgrade ) 

This is also okay right? as the OOB BR is skipped during the upgrade time, we can review that skipped log during upgrade and check as per your above correct statement.

 

approach 1 and approach 3 both are skipping the OOB BR during the upgrade time, so that we can review the skipped log and compare the code which has come through upgrade and what we have currently...

 

Please suggest

Yeah, it sounds like a good way to do it. It's safe if the OOTB business rule is reviewed during the upgrade and doesn't override your functionality.