CMDB Compliance Audit - Depends On field is failing

hanwar2 · a month ago

Hi All,

CMDB Compliance Audit - Depends On field is failing even though Depends on is clearly defined.

Has someone remediated that, if yes please let me know.

AJ-TechTrek · a month ago

As per my understanding Root Cause Analysis will be
Even though the “Depends on” relationship appears to be set in the CI, the compliance audit rule may still fail due to one or more of the following:
1. The “Depends on” field is not populated in the audited CI directly, but instead through a relationship (e.g., via a related list or CI Relationship).
2. The field mapping or condition in the audit template is incorrectly checking the wrong field or expecting a specific format.
3. Data is correct in the relationship table (cmdb_rel_ci), but the audit rule is checking the field depends_on in the main CI table, which might not be auto-populated.

Solution Steps:
1. Verify the “Depends on” field source
* Open the specific CI (Configuration Item) record that is failing.
* Ensure the “Depends on” field (reference field or relationship) is not just shown via a related list but populated as a field value.
* Sometimes relationships are shown via related lists but the field like depends_on remains null.

2. Check the Audit Template Field Definition
* Go to CI Class Manager → Audit → Template used (in this case Critical Business Services - 1).
* Ensure the Column name Depends on is referencing the correct field:
* Check if it refers to the depends_on field (sys_id) or is intended to validate CI Relationships.

3. Adjust Certification Logic If Needed
* If you're expecting the “Depends on” relationship from CI Relationship table, consider adjusting your audit to check via a Scripted Audit Rule.
* Example: var gr = new GlideRecord('cmdb_rel_ci');
* gr.addQuery('parent', current.sys_id);
* gr.addQuery('type.name', 'Depends on::Used by');
* gr.query();
* answer = gr.hasNext();
* This way, it checks relationships explicitly instead of a single field value.

4. Review the Field Population Logic
* Make sure “Depends on” field in cmdb_ci_service or related class has a populated value and not left blank when data is discovered or created manually.

5. Run Preview Audit Again
* After corrections, use “Preview Audit Results” to test the changes before next scheduled audit.

Workaround (if template limitation):
If the audit template doesn’t support relationship-based evaluation directly:
* Use a Custom Scheduled Job or Script Include to validate the relationships and populate a derived field, which can then be audited.

Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.

Thank You
AJ - TechTrek with AJ - ITOM Trainer
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
Topmate:- https://topmate.io/aj_techtrekwithaj (Connect for 1-1 Session)
ServiceNow Community MVP 2025

hanwar2 · a month ago

@AJ-TechTrek

I did try to add a field "Depends on" but still the audit is failing.

You also see that relationship for Depends on is also showing.

Can you please suggest how to resolve this.

AJ-TechTrek · 4 weeks ago

Hi @hanwar2 ,

I see the screenshot is showing the Service CI record for SAP Labor Distribution in ServiceNow with several relationship mappings already present (like Depends on – AIX Servers, Web Servers, Linux Servers, etc.), and you mentioned that you added the "Depends on" field but your CMDB audit is still failing.

From experience with CMDB audits in ServiceNow, adding the Depends on field value in the form header alone doesn’t automatically meet audit requirements, because

1. Audit checks are based on CI relationship tables (cmdb_rel_ci) — The “Depends on” field in the form is often just a reference field for display or manual entry. The actual CMDB audit logic checks if proper dependency relationships are recorded in the CMDB relationship table (and in correct direction).

2. Relationship direction matters — For example:
* Application Service A → Depends on → Server B means in the relationship table, parent is A, child is B. If the relationship is reversed (Server depends on Service), the audit may fail.

3. Audit rules are often aligned with CMDB health KPIs —
* Completeness: All mandatory fields populated.
* Correctness: Relationship types follow the model.
* Compliance: Matches the CI Class Model (CSDM).

How to fix:
1. Open the “Relationships” related list for your SAP Labor Distribution service.
* Navigate to the CI record → scroll to the Relationships section.
* Check that the “Depends on” entries are actually there in the cmdb_rel_ci table.

2. Add missing relationships properly:
* Click New in the relationships list.
* Parent = SAP Labor Distribution (this service).
* Relationship Type = Depends on :: Used by.
* Child = the dependent CI (Server, DB, etc.).

3. Check the CI Class Model:
* Use the CI Class Manager to confirm the expected relationships for the Service class.
* In CSDM, Business/Application Services must have downstream dependencies on Application/Technical Services and infrastructure CIs.

4. Run the CMDB Health Dashboard:
* Go to CMDB Health > Dashboard → pick your CI → run the audit.
* See which audit rule is failing (Completeness / Correctness / Compliance).

* This will point to exactly what’s missing.

5. Do not rely only on the “Depends on” field in the form — That’s not always tied to audit logic unless a relationship entry exists in the CMDB relationships table.

Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.

Thank You
AJ - TechTrek with AJ - ITOM Trainer
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
Topmate:- https://topmate.io/aj_techtrekwithaj (Connect for 1-1 Session)
ServiceNow Community MVP 2025