Override parent business rule(s)

Greg42
Mega Guru

Hi All,

I have extended the alm_asset table as I will need most but not all of the functionality from the parent table. I would like to change the behaviour of some of the business rules slightly and am wondering if it is possible to override it on a child table. I am also thinking about excluding my extended table on parent's business rule condition I want to change and add new one(s) on my child table - but overriding seems like a better way if possible.

Is overriding business rules on tables possible in SNow or my second idea is the way to go?

Not extending and moving functionalities I want maybe? Seems like too much of unnecessary work.

Maybe you guys have other ways for achieving it?

What would be the best way to do it?

Any hints or guidance will be much appreciated.

Cheers

Greg

1 ACCEPTED SOLUTION

Kalaiarasan Pus
Giga Sage

You can write the business rule on the parent table and script it like below to apply it to specific table.



if(current.sys_class_name='tablename1')


{


code


}



if(current.sys_class_name='tablename2')


{


code


}


View solution in original post

8 REPLIES 8

Kalaiarasan Pus
Giga Sage

You can write the business rule on the parent table and script it like below to apply it to specific table.



if(current.sys_class_name='tablename1')


{


code


}



if(current.sys_class_name='tablename2')


{


code


}


This is the correct answer, but unfortunately it involves marking the rule as having a customer update, which prevents future patch updates.



There is a way to override UI actions on extended tables (by re-using the action name), and some of the new applications / integrations ServiceNow provides use a factory / wrapper construct, which allows you to add customizations without updating delivered code. That's not an option in most base apps though.



Another option depends on what the OOB rules are doing.   If they're before-insert / before-update, you can add business rules to your extended table with the Order value set immediately after those OOB rules, and revise whatever they did (as long as they didn't modify customer input -- you won't know what the values the customer added were ... unless you add yet another business rule on your extended table set before the OOB rule to save those entries in the scratchpad or something, for your 2nd business rule to then grab). This is getting rube-goldbergian -- kalai's reply is the standard.


Thank you guys for the input.



What do you think about copy/paste the OOB, deactivate the OOB and then change it? Will that make future updates work or deactivating a BR makes me the owner straight away?



Cheers


The 'active' checkbox still counts as a customer update and it will still be skipped.   I've still used this method, to make it easier to track SN's code changes with the larger script includes I've needed to edit.   Picking them out from the list of 16,000 skipped updates is the main issue.