No. No it does not.

Now that we have that out of the way, you may ask yourself - quite rightfully so - why you have never heard of that field. It is present on other scripting parts on the platform such as UI Actions.

The sys_override for business rules does do exactly what you would think it does. It overrides - as in "Trigger this, not whatever i am overriding" - another business rule preventing the overridden one to be executed. BUT: Only if those business rules are within different domain scopes. It works with domain separation, but not outside of it (yet).

Now, why should you care?

Imagine a world where you would not have to touch ootb business rules. Where customization for a process could reside within an easy to maintain and deploy application. Where said application could have its own scope, its own functions and developers could be very restrictive with the way customizations are interaction with each other. Now imagine if you could have such customizations as a blueprint to "override" ootb processual behaviour.

Welcome to a world where the sys_override field actually works outside of the domain separation. A world where "going back to ootb" is just a click away - that click being called "uninstall" on the application itself. A world where you could put your "improved" yet customized incident process to the store and people could try it out in an instant. Welcome to a world which does not yet exist.

Issue is: If you want your customization to reside within an application scope, said application scope cannot contain changes to the global scope or any other scope. Setting business rules to inactive does not work.

Why does it not work? I don't know. ServiceNow: Please fix.