If you're extending a VR Integration Framework processor (Wiz CC, Qualys CC or any processor built on sn_vulc.ComplianceTestResultBase) and want a new field to show up on the Test Result record, there's one pattern to know and one gotcha that trips almost everyone up.

 

Note: this is based on reading the shipped script include source, not published documentation — ServiceNow doesn't document this mechanism publicly, so treat it as "how the code behaves today," not a guarantee.

 

The pattern

Every processor built on ComplianceTestResultBase builds a plain object (newTestResult()), fills in field values, and hands it to createOrUpdateTestResult(). That method checks whether a matching record already exists (same cmdb_ci + control + integration_instance) and routes to one of two internal methods, and this is where the behavior splits.

 

The scenario

Lets say we would like to include a specific field that is within our Wiz payload (import row) for Configuration Compliance.

 

Step 1: get the value onto your object

Locate the processor (sys_script_include) of "sn_vul_wiz.WizConfigurationFindingsProcessor".

In your processor's record handler, assign the value using the exact column name from sn_vulc_result:

testResultObj.your_field = sourceGr.getValue("u_your_source_field");

 

Step 2: register it as a custom source field

var customSourceFields = ["description", "remediation", "result", "your_field"];
this.testResult.setCustomSourceFields(customSourceFields);
this.testResult.updateCustomFields = true;

 

Step 3: know the difference before you test

	Insert (createTestResult)	Update (updateTestResult)
Behavior	Writes every key on your object, registered or not	Writes only the fixed core fields, plus anything in your customSourceFields array,  only if updateCustomFields = true

This means a new field will work the first time you import a finding, then silently stop updating the second time the same finding comes through. If you only test with a brand-new record, you won't catch it.

 

**Always test insert and a re-scan of the same finding separately.**

 

Data flow:

 

 

Checklist

• Field exists and is writable on sn_vulc_result
• Value assigned on the testResultObj inside your record handler
• Field name added to the setCustomSourceFields() array
• updateCustomFields = true needs to be set on the processor sys_script_include (sn_vul_wiz.WizConfigurationFindingsProcessor)
• Tested both on first import and on a repeat scan

 

NOTE:

There is no ServiceNow-published content for setCustomSourceFields() / updateCustomFields behaving as described here. It was determined by reading the live script include source, not from docs.servicenow.com ~ TREAT THIS AS A CUSTOMIZATION AND MAINTAINED AS SUCH.

 

Skips-during-upgrade risk applies: any ServiceNow upgrade that touches these script includes may silently overwrite this customization. This must be tracked as a customization and re-validated after every upgrade to the VR / Configuration Compliance store apps.

|