Synopsis and Purpose
CI Sync contains default rules that control how CIs are retired vs deleted in the CMDB. These rules are applied differently depending on whether CIs are treated as Primary vs Secondary record sets within CI Sync.
This FAQ explains key concepts about the above topics and associated rules so customers understand which CI types are never deleted by CI Sync, and which CI types are deleted by CI Sync.
General Context of Insert vs Update vs Delete & Retire
By definition, CI Sync when processing a record set will:
-
Insert CIs into the ServiceNow CMDB → if the record in the Source System is new and does not exist in the CMDB.
-
Updates records into the ServiceNow CMDB → if the record in the Source System has changed but already exists in the CMDB.
-
Deletes or Retire records from the ServiceNow CMDB → if the record in the Source System is no longer visible to CI Sync (in the record set).
Please read the two sections immediately below for important notes about Delete or Retire operations and how this is implemented depending whether records relate to Primary CIs/assets vs Secondary CIs.
General Context of Primary vs Secondary Record Sets
CI Sync maintains a distinction between Primary record sets (sometimes referred to as “Parent” CIs/assets) and Secondary record sets (sometimes referred to as “Child” or “Sub-Component” CIs)
-
Examples of a Primary/Parent record set/CI/asset are: Windows Servers, Windows PCs, Switches, Routers, etc.
-
Examples of a Secondary/Child record set/CI are: Installed Software records, Network Adapters, Memory Modules, Disk Storage, Switch Ports, etc (i.e. these are examples of “sub-components” of a Primary/Parent record set/CI/asset).
Specific Details about Delete or Retire Operations
By design, CI Sync delete vs retire rules are applied differently between Primary record sets (sometimes referred to as “Parent” CIs/assets) and Secondary record sets (sometimes referred as a “Child” CI, or a “Sub-Component” CI or a “Peripheral” CI)
-
For Primary record sets, CIs are never deleted.
-
Instead, Primary CIs are only Retired in the CMDB by CI Sync setting Installed Status, Operational Status and Hardware Status value to “Retired”.
-
-
For Secondary record sets, in the vast majority of cases CIs are deleted from the CMDB. Additional notes follow:
-
Deleting these records ensures the Child/Sub-Component/Peripheral CIs do not create an endlessly growing list of these Child CIs.
-
This makes sense if you consider the real-world nature of Child/Sub-Component/Peripheral CIs.
-
Take Installed Software as an example. When an application (i.e. a piece of installed software) is removed from a Windows PC, it is sensible to delete the Installed Software Child CI so the Parent CI/asset doesn’t contain a list of old/removed applications.
-
Special Handling of Windows Displays/Monitors (from Lansweeper On-Prem)
This section provides specific details about Windows Display/Monitor CIs in addition to the processing context notes above.
As explained by the following points, Windows PC and Server Displays/Monitors are a special case because Syncfish customers want to Displays/Monitors differently depending on their business requirements. Customer feedback has told Syncfish of the following two use cases.
-
Some customers don’t manage Displays/Monitors as a fixed asset. This is consistent with ServiceNow default configuration which identifies discovered Displays / Monitors will not generate hardware assets - as such, these customers treat Displays/Monitors as a low value peripheral that does not need to be managed as an asset. In this situation CI Sync can treat Displays/Monitors as a Secondary record set (i.e. as a Child CI) to be deleted when no longer seen by the source system).
-
Other customers do manage Displays/Monitors as a fixed asset. These customers treat Displays/Monitors as having sufficient capital value to warrant performing fixed asset management practices to them (depreciation schedules, and so on) and an accompanying update of ServiceNow configuration is required to identify that discovered Displays / Monitors should generate hardware assets In this situation CI Sync can treat Displays/Monitors as a Primary record set (i.e. as a Parent CI) to be Retired via a Status value update when no longer seen by the source system).
The history of the above topic needs further explanation:
-
Until early 2026 CI Sync always treated Displays/Monitors as a Secondary record set (i.e. as a Child CI) to be deleted when no longer seen.
-
This means Displays/Monitors have in all cases been deleted for existing Syncfish customers up until February 2026.
-
This often goes unnoticed because ServiceNow’s default configuration causes Displays / Monitors to NOT generate hardware assets (i.e. ServiceNow’s default position of not treating Displays/Monitors aligns with Syncfish’s historical default).
-
-
In early 2026, at the request of two customers wanting Displays/Monitors to be Retired not Deleted, Syncfish introduced a CI Sync Connection Setting so customers can decide individually how they want Displays/Monitors to be handled. Customers can decide:
-
Whether to treat Displays/Monitors as a low value Peripheral (in which case they are deleted when no longer seen by the source system)
-
Or to NOT treat Displays/Monitors as a low value Peripheral (in which case they are Retired via a Status value update when no longer seen by the source system).
-
Importantly
-
For existing Syncfish customers up until February 2026, Displays/Monitors have always been deleted (this is not a recent behaviour, it has been the case since CI Sync was first rolled out many years ago).
-
When the new customer definable setting was introduced, Syncfish did not change the historical default (i.e. Syncfish did not force a change in the default behaviour across all existing customers).
-
The historical behaviour is not a defect with CI Sync. Instead it was a conscious design position based on customer input five to six years ago when CI Sync was first built, backed up by the ServiceNow default configuration which identifies the discovery of Displays / Monitors will not result in the generation of hardware assets.
This was likely influenced by Displays/Monitors being lower value and not needing the overhead of fixed asset management processes.
Additional Important Reads
The related articles section below contains important information for customers wanting to control the end-to-end bheaviour of displays/monitors across Lansweeper, CI Sync and ServiceNow.
Related Articles
-
CI Sync Default Configuration Guides (How CI Sync handles Displays/Monitors from Lansweeper On-Prem)
-
CI Sync Default Configuration Guides (How CI Sync updates ServiceNow Status Values on CIs)
-
CI Sync Connection Setting (to Synchronize Displays/Monitors as Peripherals or Not from Lansweeper On-Prem)
-
How to prevent Lansweeper for Automatically Inactivating (and Deleting) Displays within Lansweeper
Control Information
|
Created |
|
|---|---|
|
Reviewed |
|
|
Data Classification |
PUBLIC
|