Hi @SuvithaMuru,
This is documented OOB behavior, not a hidden script someone snuck in. Your screenshot actually confirms it: that confirmation dialog ("Are you sure you want to deactivate this Control Objective? The following will be deactivated/retired: Control (1 record(s))") is the platform warning you before it does exactly that.
The mechanism behind it is a business rule ServiceNow ships called Cascade Changes, sitting on the Control Objective table (sn_compliance_policy_statement, still called Policy Statement under the hood even though the UI label is Control Objective). It fires when you flip the Control Objective's Active checkbox off (which is what drives it into Inactive/Retired), and it walks the related list down to every Control (sn_compliance_control) linked to that objective and pushes them to Retired. When you reactivate the Control Objective, the same rule brings its Controls back, but to Draft, not to whatever state they were in before, since it treats the reactivation as a fresh revision cycle.
A few things worth checking if this is confusing you in a specific scenario:
- Where to look for it: filter Business Rules (sys_script) on table sn_compliance_policy_statement, name contains Cascade. You'll find it there, it's an OOB rule, not a UI Action, so it won't show up if you're only scanning UI Actions on the form.
- Policy state matters too: if the Control Objective is attached to a Policy that's already Published or beyond Draft, the objective itself becomes read only for direct edits, so deactivation there usually has to flow through the policy lifecycle rather than the objective form.
- One Control, multiple objectives: if a Control is linked to more than one active Control Objective, deactivating just one of them may not retire it, since the rule is evaluating the aggregate state of everything the Control rolls up to. Check the Control's related Control Objectives list before assuming the cascade should have fired.
Worth flagging: if you're on a recent release, this whole area changed. Starting with the Australia release, ServiceNow replaced the old "edit immediately cascades live" model with a proper Control Objective Workflow, staged revisions with Major/Minor versioning and configurable approvals, specifically because the old Cascade Changes rule used to reset every associated Control to Draft on any live edit, including a typo fix, which caused a lot of unwanted mass re-attestation. So depending on your version, the exact trigger conditions and downstream state may differ slightly from the classic behavior described above.
References
Thank you,
Vikram Karety
Octigo Solutions INC
