Question
Syncfish frequently receives questions regarding CI synchronisation and possible impacts on ServiceNow Asset Management after implementation of CI Sync.
Some of the common questions Syncfish receives:
Why are the CIs created by CI Sync user not also creating Hardware Asset records in Asset Management?
Why is the CI Sync user updating attributes of Hardware Asset records in Asset Management?
Why has a CI Sync job changed the status of a Hardware Asset from “In stock” to “In use”?
Why has a CI Sync job removed the stockroom assigned to a Hardware Asset?
For simplicity this article will focus on Hardware Assets and all asset references are specific to Hardware Assets unless expressly identified otherwise.
Quick answer
ServiceNow recognises there is a direct relationship between an asset and a CI although they are managed as separate records, the Hardware Asset represented in the Asset Management application for tracking a physical device from a financial and lifecycle management perspective and the CI represented in the CMDB to track an IT device from an IT operations perspective for use in ITSM applications.
As the ServiceNow asset record and CI record are separate records representing the same device, out-of-the-box functionality exists to keep these record in sync with each other which is both intentional and desirable.
Some example scenarios where asset and CI syncing occurs:
-
creation of a new CI such as a Computer triggers the creation of a new Hardware Asset
-
creation of a Hardware Asset within the Computer category triggers the creation of a new Computer CI
-
updates to CI attributes through discovery / scanning via CI Sync (e.g. asset tag) triggers an update to the corresponding fields on the linked asset
-
updates to an asset from an asset lifecycle perspective to identify a computer is now allocated and “in use” triggers an update to the linked CI’s status
-
updates to CI status to identify a computer is retired (e.g. CI Sync / Lansweeper “not seen” behaviour) triggers an update to the linked asset’s status
Coming back to the questions originally posed at the start of this article, the answers are now quick clear…
Why are the CIs created by CI Sync user not also creating Hardware Asset records in Asset Management?
ANSWER: CI Sync will only create CI records but ServiceNow asset / CI synchronisation by design will trigger creation of a linked asset based on the existing Model Category records.
Why is the CI Sync user updating attributes Hardware Asset records in Asset Management?
ANSWER: CI Sync only directly updates CI records but ServiceNow asset / CI synchronisation by design will trigger an update to attributes on linked assets based on pre-configured mapping rules.
Why has a CI Sync job changed the status of a Hardware Asset from “In stock” to “In use”?
ANSWER: CI Sync only directly updates CI records but ServiceNow asset / CI synchronisation by design will trigger status updates to linked assets based on pre-configured mapping rules.
Why has a CI Sync job removed the stockroom assigned to a Hardware Asset?
ANSWER: CI Sync only directly updates CI records but if a CI becomes active forcing an Install status update, ServiceNow asset / CI synchronisation will trigger a pre-defined business rule which says the current stockroom should be removed from assets which are no longer in stock.
Long answer
There is a significant amount of configuration involved when it comes to asset and CI synchronisation behaviour in ServiceNow which alters the way this works.
To further complicate matters:
-
Enhancements have been introduced in ServiceNow releases over time which may or may not have been activated or completely implemented as part of a customer’s instance maintenance practices.
-
Long-standing ServiceNow customers with the best of intentions may have customised the default behaviour to fill a gap and / or satisfy a business process requirement which no longer applies or has been replicated by default platform behaviour.
Due to the above, a customer may find that the behaviour they are seeing in their ServiceNow instance is not mirroring the best practice processes implemented by ServiceNow as described in documentation to support automated Asset and CI synchronisation.
Alternatively, if you want to understand more about Asset and CI synchronisation behaviours, this article will provide all that you need.
References
All of the resources referenced in the table below are an excellent source of information when it comes to the subject of Asset and CI synchronisation in ServiceNow. Reviewing these resource in conjunction with the other information presented on this page will be valuable.
|
Topic |
Reference |
|---|---|
|
Key document - overview of CI and Asset interactions Whilst this document is nested under Hardware Asset Management in ServiceNow Docs, with HAM being a paid product, the information still applies generally to Asset Management |
https://docs.servicenow.com/csh?topicname=c_ManagingAssets.html&version=latest |
|
Pre-allocated asset process |
https://www.servicenow.com/docs/csh?topicname=manage-preallocated-asset.html&version=latest |
|
How to stop duplicates created when the discovery source in asset is set to SNAssetManagement |
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1219620 |
|
Map asset and CI fields |
https://www.servicenow.com/docs/csh?topicname=t_CreateAssetandCIFieldsMapping.html&version=latest |
|
Map asset state and CI hardware status |
|
|
Map asset state and CI install status |
|
|
Product Success Playbook - Enable Create CI on Asset Insert Business Rule |
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0999333 |
|
Product Success Playbook - Ensure Hardware CI - Asset Linkages |
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1302907 |
|
Get Well Playbook - Hardware CIs without Serial Numbers |
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0829077 |
Best practice platform configuration
If you want a quick reference to the base configurations / scripts which drive the best practice asset and CI synchronisation behaviours in ServiceNow, then you will find this in the table below.
Syncfish recommend reviewing these items in the first instance before moving ahead in this document.
|
Configuration / script |
Expected state |
|---|---|
|
Business rule “Create CI on insert” |
Active and non-customised |
|
Business rule “Create Asset on insert” |
Active and non-customised |
|
Business rule “Update CI fields on change” |
Active and non-customised |
|
Business rule “Update Asset fields on change” |
Active and non-customised |
|
Script include AssetAndCISynchronizer |
Active and non-customised |
|
Script include AssetandCI |
Active and non-customised |
|
Script include AssetCMDBUtil |
Active and non-customised |
|
System property glide.asset.create_ci_with_ire |
Set to “true” |
Example scenarios and related ServiceNow configurations
In this section, we will unpack some specific scenarios and identify the related ServiceNow configurations which are critical to unlocking the expected behaviour.
A couple of things to note before moving on:
-
The configurations identified in the scenarios below are for tweaking / adjusting behaviours after the items listed under Best practice platform configurations table are reviewed.
-
If you have licensed the IT Asset Management product (one or both of Software Asset Management and Hardware Asset Management), there are some enhancements which apply to matching an asset to an existing CI involving the network adapter of a device and associated MAC address. This isn’t covered in this document as the principles of matching based on CI Identifiers still applies and the majority of customers will be using the base Asset Management product.
Create new asset scenario
Scenario: New record is inserted in alm_hardware table in ServiceNow (either via submitting the respective UI transaction or an integration which triggers business rules)
The table below identifies specific actions which take place and how they are triggered as part of default platform behaviour. For troubleshooting purposes, the related configuration(s) are identified.
|
Action |
Trigger(s) |
Related configuration(s) |
Troubleshooting |
|---|---|---|---|
|
Decide if creation of a CI is indicated |
Automated from creation of new alm_hardware record |
|
If CI creation is not being triggered, check the following:
|
|
Map asset status to CI status |
Automated from creation of new alm_hardware record |
|
If the CI’s status fields are not being initially set as expected from the linked asset, check existing mappings as per Asset-CI Install Status Mapping and Asset-CI Hardware Status Mapping. Refer to the ServiceNow documentation on status mapping for a better understanding of which status fields are correlated between asset and CI. |
|
Map asset field values to CI field values |
Automated from creation of new alm_hardware record |
|
If the CI’s field values are not being initially set as expected from the linked asset, check mappings as per Asset-CI Field Mapping |
|
Duplicate CI check |
Automated from creation of new alm_hardware record |
|
If there is a pre-existing CI which "matches” the asset (e.g. same serial number) and a new CI is being created anyway OR asset creation is being rejected, review the related configuration(s) noting the following behaviour which applies to system property glide.asset.create_ci_with_ire:
|
Create new CI scenario
Scenario: New CI is inserted in cmdb_ci_hardware table (or a child class table) in ServiceNow (either via submitting the respective UI transaction or an integration such as CI Sync which triggers business rules)
The table below identifies specific actions which take place and how they are triggered as part of default platform behaviour. For troubleshooting purposes, the related configuration(s) are identified.
|
Action |
Trigger(s) |
Related configuration(s) |
Troubleshooting |
|---|---|---|---|
|
Decide if creation of an asset is indicated |
Automated from creation of new CI record |
|
If asset creation is not being triggered, check the following:
|
|
Map CI status to asset status |
Automated from creation of new CI record |
|
If the asset's status fields are not being initially set as expected from the linked CI, check existing mappings as per Asset-CI Install Status Mapping and Asset-CI Hardware Status Mapping. Refer to the ServiceNow documentation on status mapping for a better understanding of which status fields are correlated between asset and CI. |
|
Map CI field values to asset field values |
Automated from creation of new CI record |
|
If the CI’s field values are not being initially set as expected from the linked asset, check mappings as per Asset-CI Field Mapping |
Update asset scenario
Scenario: Update of record in alm_hardware table in ServiceNow for an asset linked to a CI (either via submitting the respective UI transaction or an integration which triggers business rules)
The table below identifies specific actions which take place and how they are triggered as part of default platform behaviour. For troubleshooting purposes, the related configuration(s) are identified.
|
Action |
Trigger(s) |
Related configuration(s) |
Troubleshooting |
|---|---|---|---|
|
Map asset field values to CI field values |
Automated from update of new alm_hardware record |
|
If the CI’s field values are not being updated as expected from the linked asset, check mappings as per Asset-CI Field Mapping |
|
Map asset status to CI status |
Automated from update of new alm_hardware record |
|
If the CI’s status fields are not being updated as expected from the linked asset, check existing mappings as per Asset-CI Install Status Mapping and Asset-CI Hardware Status Mapping. Refer to the ServiceNow documentation on status mapping for a better understanding of which status fields are correlated between asset and CI. |
Update CI scenario
Scenario: Update of CI in cmdb_ci_hardware table (or a child class table) in ServiceNow for a CI linked to an asset (either via submitting the respective UI transaction or an integration such as CI Sync which triggers business rules)
The table below identifies specific actions which take place and how they are triggered as part of default platform behaviour. For troubleshooting purposes, the related configuration(s) are identified.
|
Action |
Trigger(s) |
Related configuration(s) |
Troubleshooting |
|---|---|---|---|
|
Map CI field values to asset field values |
Automated from update of CI record |
|
If the asset’s field values are not being updated as expected from the linked CI, check mappings as per Asset-CI Field Mapping |
|
Map CI status to asset status |
Automated from update of CI record |
|
If the asset's status fields are not being updated as expected from the linked CI, check existing mappings as per Asset-CI Install Status Mapping and Asset-CI Hardware Status Mapping. Refer to the ServiceNow documentation on status mapping for a better understanding of which status fields are correlated between asset and CI. |
Closing thoughts
Given the technical nature of some of the information provided in this article, it may seem like it is quite complicated to reach a position where Asset and CI synchronisation is working as expected, but it is important to understand the key configurations which exist and impact the desired synchronisation behaviour, preventing ServiceNow and CI Sync from working in harmony with each other.
The first step is to review the key ServiceNow technical configurations as per Best practice configuration section above and seek to adopt an out-of-the-box state. This should be a relatively simple activity and is a once-off task. Please reach out to Syncfish if you would like a review of your ServiceNow configuration to address customisations.
With the ServiceNow technical configurations addressed, the next logical step is to clearly identify the critical asset fields (e.g. from a lifecycle and financial perspective) which should not be updated from CI updates i.e. as a result of ongoing device discovery and synchronisation of the CI through CI Sync jobs. To make this easier, it can be useful to have the end-to-end lifecycle of an asset mapped out to understand how CI status updates can influence the asset lifecycle and associated attributes of the asset.
After reviewing the information in this article and making necessary changes, if you believe that more advanced configuration is required to have CI Sync observe the current value of fields or status of the CI or asset in ServiceNow before making a decision on field syncing, please reach out to Syncfish to discuss.
Related Articles
CI Sync config overrides for status mapping - https://support.syncfish.com.au/cs/ckb039-how-to-when-i-move-a-device-to-a-status-of-
Control Information
|
Created |
|
|---|---|
|
Reviewed |
|
|
Data Classification |
PUBLIC
|