Best Practice in OOB

[Mike Allen]

There are several instances of OOB scripts not falling with proper best practice, even according to ServiceNow's own best practice guides.   They use things like constructors vs. literals, missing semi-colons, using eval, etc.   I'm of the mind to let sleeping dogs lie, but seeing these things still bugs me.   So, I'd like to discuss a few things:

a) does SN plan to revisit old code to bring them up to their own prescribed best practice?

b) what should we do if we see these things?   Fixing them may trigger the customer update skip in version upgrades.

[robertmaxwell]

2. Mark the OOB script inactive and create your own copy. This way the script is still caught in updates.

[Mike Allen]

We've deactivated OOB scripts and the following line seems to tell me that it will not be caught in upgrades:

<sys_customer_update>true</sys_customer_update><sys_domain>global</sys_domain><sys_domain_path>/</sys_domain_path><sys_id>245748ecc61122aa016c02dffbff7464</sys_id><sys_mod_count>5</sys_mod_count><sys_name>Incident Create Knowledge</sys_name><sys_overrides/><sys_package display_value="Knowledge Management" source="com.glideapp.knowledge">dbcdefd2db70320090cafe1ebf9619f5</sys_package><sys_policy/><sys_replace_on_upgrade>false</sys_replace_on_upgrade>

[Goran WitchDoc]

That is real strange... I would report it to ServiceNow... I mean, this what I heard all the time as well, inactivate something doesn't count as a "customization". Anyway, now days customized stuff gets upgraded, but the new version isn't set as "current". I think it get state that is named something like History...

//Göran

[robertmaxwell]

Hi Mike

On further investigation you are correct.

Marking the script inactive is actually a customisation

Way around it is to then change replace on upgrade to true as you should not alter the sys_update_xml file

Overwrite a customization during an upgrade