Configuration Compliance Remediation Tasks auto closure?

drestoker1
Tera Contributor

What is the normal closure process for remediation tasks (CRGs) in Configuration Compliance when updating Test Result state? 

 

We are seeing an issue where CRGs are closing as soon as one of the associated Test Results close. This doesn't seem correct and severely effects our ability to use CRGs effectively. We would like to configure the CRGs to close only if ALL of the associated Test Results are closed. Is this possible?

 

 

4 REPLIES 4

wojasso
Giga Guru

Hi @drestoker1

The behaviour you're seeing is governed by the Configuration Compliance “remediation group” aggregator that runs periodically to roll up the state of individual Test Results into the group. It looks at the Is closed flag on each Test Result state and when every result in the group has a closed state the group is marked complete. There isn’t any built‑in logic to close the CRG after the first result closes.

  • Check the Test Result State records (sn_cc_test_result_state) in your instance. Only states that should count as closed should have the Closed and Is closed flags set. If intermediate states such as “Mitigated” or “Risk Accepted” have is_closed = true, the group will close as soon as one result hits that state.
  • The scheduled job Configuration Test Result Group Aggregator (or the ccRemediationGroupAggregator Script Include) drives the status calculation. Make sure this job hasn’t been customized to auto‑close on the first closure.
  • If you want to change the closure rules, you can override the group aggregator logic or add a business rule on the sn_cc_test_result_group table that checks whether all results are closed before changing the group’s state. However, be aware that modifying the aggregator script can complicate future upgrades.
  • For out‑of‑box behaviour it should require all test results to be closed. If you’re on a recent release and haven’t customized anything, open a support case – there was a defect in some early CC releases that caused groups to close prematurely when the first item closed.
var results = new GlideRecord('sn_cc_test_result');
results.addQuery('group', current.sys_id);
results.addQuery('state.is_closed', true);
results.query();
if (!results.next()) {
  // at least one result is still open
  current.state = 'in_progress';
} else {
  current.state = 'closed';
}



💥 Was this answer useful? 👏 If so, click 👍 Helpful 👍 or Accept as Solution 💡💪💻👍

drestoker1
Tera Contributor

None of the tables or scheduled jobs you mentioned exists. 

The opening scope is sn_vulc, instead of the sn_cc referenced.

 

Even when using sn_vulc the tables do not populate