Skip to content
CMDB Alternatives Compare

LESSON 8 OF 10 · Keeping it true · 3 MIN

Writing corrections back to ServiceNow safely

SHORT ANSWER

A corrected record that never reaches the CMDB changes nothing. Writing back automatically is powerful, so start with creating missing records, add updates field by field, and leave retirement for last with a review step.

By The Record Desk · CMDB Alternatives Compare · Published 2026-09-21 · Updated 2026-10-11

Why write back at all?

If the accurate picture lives in a separate tool, people still read the CMDB for incidents, changes and audits. The gap stays where the decisions are made. Writing back closes it: the CMDB becomes as current as the best data you have.

What can write back mean?

Three different actions, with different risks:

  • Create: add a record for an asset the CMDB does not have. Low risk; the worst case is a record someone later merges.
  • Update: change a field on an existing record. Medium risk; a wrong rule overwrites good data.
  • Retire: mark a record as disposed or remove it. Highest risk; a wrong rule hides a live system.

Axonius documents all three for ServiceNow as enforcement actions: "ServiceNow - Create Assets", "ServiceNow - Update Assets" and "ServiceNow - Disable or Remove Assets". Its CMDB Reconciliation Workspace, announced on 22 July 2026, lists assets missing from the CMDB and mismatched fields and can create missing records through its Action Center.

How do other options reach the CMDB?

Oomnitza describes bidirectional sync with ServiceNow that writes validated values, including owner, location and lifecycle status, back to the CMDB and reconciles daily. Lansweeper sends inventory into ServiceNow, Jira Service Management, HaloITSM, Freshservice and TOPdesk. Armis pushes enriched data back to the CMDB. runZero's integration enriches the CMDB. Device42 integrates with ServiceNow, Freshservice and Jira. JupiterOne's ServiceNow integration doc describes ingesting CMDB classes; writing back is not stated there. ServiceNow's own Discovery and Service Graph Connectors write natively.

What order should you switch things on?

  1. Report only: list what would change for two weeks and review it.
  2. Create missing records automatically.
  3. Update a small set of fields where the source of truth is clear, such as serial number and operating system.
  4. Add more fields one at a time, each after a review of the first run.
  5. Retire records only after a review step, for example a ticket to the owner before anything is disabled.

What should be logged?

Every automatic change should say which source and which rule made it, so a wrong change can be traced and reversed. Keep the previous value.

Who approves the rules?

The CMDB owner should approve every write-back rule, because they answer for the record. Security and infrastructure teams can propose rules, but one approver keeps changes consistent and makes a reversal quick when something goes wrong.

How does this show in our scores?

Keeping the CMDB in sync carries 16% of the weight. Axonius leads at 92 because it documents create, update and retire actions for ServiceNow records; ServiceNow CMDB scores 86 as the system of record with native discovery.

Next lesson

Lesson 9 of 10

Measuring CMDB accuracy with numbers you can defend

Accuracy needs a few simple, repeatable measures: coverage against trusted outside lists, a sampled correctness rate, duplicate and ghost counts, owner coverage and record age. Track them monthly and publish them to the teams who use the record.