Data Certification tracking Reports or Visualizations
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
For the Data Certification CMDB Tasks, we want to track items via Reports or Visualizations:
1. Failed Tasks with Comment
2. CI Attributes manually updated within the Certify Task and later overwritten by some Automation
Which Tables should we use?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Failed Tasks with Comments
If you’re on Washington DC or later (CMDB Workspace / Data Manager), the old cert_element table is no longer relevant. Instead, use these:
sn_cmdb_ws_dm_certification_attribute_status → Attribute‑level results. If someone fails an attribute and adds a comment, it’s stored here.
sn_cmdb_ws_dm_certification_task_to_document → Connects each certification task to its CI records.
cmdb_data_management_task → The parent task record (assignee, policy, state).
cmdb_data_management_task_find → Modern replacement for cert_element. One record per attribute checked, with expected vs. actual values and pass/fail.
cmdb_data_management_policy_execution → Lets you slice reports by policy run or execution date.
How to report it:
Join cmdb_data_management_task with cmdb_data_management_task_find.
Filter on status = Failed.
This gives you Task Number, CI, Field Name, and the failed value.
If you want more context, build a Database View that also pulls in cmdb_data_management_policy_execution so you can filter by policy and run date.
If you’re still on legacy Data Certification, use cert_task for the task record and cert_element (filtered on status = Failed) for attribute failures.
Attributes Manually Updated During Certification, Later Overwritten by Automation
This is trickier, because you need to detect changes after a certifier manually set a value.
Step‑by‑step approach:
1. Baseline:
Use sn_cmdb_ws_dm_certification_attribute_status.
It captures the certified value and the exact timestamp when the certifier updated it.
2. Check for overwrites:
Query sys_audit for the same CI and field.
Look for changes after that certification timestamp.
If the updated_by field shows a system account (Discovery, integration user, etc.), that’s your automation overwrite.
3. Confirm source:
Use cmdb_ire_result_log to see if the overwrite came through IRE (Discovery, Service Graph Connectors, etc.).
4. Understand precedence:
Check cmdb_datasource_precedence to see why automation was allowed to overwrite (which source has authority over which fields).
sys_audit only logs changes for fields where auditing is enabled in the dictionary (Audit = true). If auditing isn’t turned on for those CI attributes, you won’t see anything. In that case, you’d need a custom Business Rule to log those events to a separate table.
