Assets, Configuration Items, and Model Categories: understanding how they work together

[Mathew Hillyard]

Assets vs CIs

Those of you who have previously worked in IT Service Management, on a service desk handling incidents and requests on Configuration Items (CIs) or services made up of multiple CIs, as a configuration manager or CI owner, or within asset management, dealing with the financial and contractual/leasing requirements of your company's asset estate, will be familiar with the challenges of dealing with the two halves of the same entity within ServiceNow.

Customers typically view an asset as a single entity from all points of view - both a physical or logical item that makes up a service (or a standalone CI, like an end user device) - and the financial and contractual elements. However, ServiceNow, with a nod towards frameworks like ITIL, views asset management and configuration management as separate, distinct processes, and therefore treat these use cases with different records for the same entity. 

An asset is intended to assist with tracking through financial, contractual and leasing lifecycles. 
A configuration item is used to track operational and relationship information - basically it's a record in your Configuration Management Database (CMDB).

You can assign financial values to either an asset or a CI, but more specialised financial information, like contract-related data such as depreciation or leasing should be referenced via the asset.

This has some advantages - for example, you can tailor the specific record and the processes around it, without polluting the record with elements the opposing process - but it comes with the added complexity of referencing, using, and maintaining two records for each entity.

Consumable Assets are a particular class of Asset where you wish to store that you have purchased a quantity and total cost of lower-value Assets, or Assets that you would not normally track by Serial Number. Such Assets are excluded from automatic sync for the simple reason that CIs aren't relevant.

ServiceNow manages this complexity with two platform artefacts: the Model Category record and the Business Rules that support it.

Model category

The Model Category record's primary function is to drive the automatic creation of assets and CIs. If a Model Category record contains a reference to both an Asset class and a CI class, then if one is created, the other will be created automatically, depending on certain conditions (see Automatic record creation exceptions below).
You can change the asset class on a model category after creation (which itself will trigger jobs to update related records), but not the CI class.

Many customers like to report on the types of device on their estate. Model Category initially seems a good choice as it usually the name of the device "type"; however be careful of this when designing reports, as the Model Category field on the Asset table is a reference, but on the Model table it is a list collector, meaning Assets by Model Category will work, but Models by Model Category will not (grouping by list collector variables is not supported, for obvious reasons).

There are 127 Model Categories contained shipped with an OOTB instance. Just like Asset classes and CI Classes, consider carefully before creating more Model Categories unless you have a very good reason. For Software, the default Software License Model Category will usually suffice, as a software asset is really an entitlement to use reflected by a corresponding Asset Covered record linking the Asset to a Contract, rather than a CMDB artefact, so does not normally need to have a corresponding CI.

Business Rules

Business rules are in place to manage both the automatic insert and update of changed attributes on either Asset or CI.

The functionality for managing insert of Assets and CIs is located within a script include called, unsurprisingly, AssetandCI. 

The following Business rules call functions and use constants from this script include:

Configuration Item table (and extended tables)

• AssetandCI
• Create Asset on insert
• Create asset on model change

Asset table (and extended tables)

• Build bundle components on Insert
• Create CI on insert

For synchronizing asset and CI updates, script include AssetAndCISynchronizer is used.

Configuration Item table (and extended tables)

• Update Asset fields on change

Asset table (and extended tables)

• Inherit information from parent
• Trickle information down to components
• Update CI fields on change

Sync'ed Attributes 

The sync'ed attributes are sensibly stored within their own table - Asset CI Field Mapping [alm_asset_ci_field_mapping]. This offers the flexibility to extend what is mapped as well as to map fields that are not identical in the Asset and the CI. Just keep in mind what each record was designed for and resist the temptation to create configuration type fields on the Asset tables or asset type fields on CI tables! If you have a critical requirement to show such a value on a form or list, then consider dotwalking from the field in the correct table - as always being mindful of performance, of course.

Automatic record creation exceptions

There are a few exceptions to the automatic creation of Assets and CIs where the Model Category contains both Asset and CI classes:

The Asset must

1. Not be a Consumable Asset
2. Not be a License Asset
3. Not have a value in its Configuration Item field
4. Not have a Substatus of Pre-allocated
5. Contain a Model Category that has a value in its CI class field

The Configuration Item must

1. Not have a value in its Asset field OR
2. Have a value in its Asset field which is NOT the current CI record
3. Not be a CI table that is one of those excluded from being applicable for automatic creation. Unfortunately the tables excluded are impossible to define as the function call is private to ServiceNow: SNC.CMDBUtil.isExcludedFromBR(current.getTableName())

If Enforce CI Verification is selected on the linked Model Category in scope, the asset will not be created automatically when a CI is created. None of the OOTB model categories have this field ticked, but if you decide to do so, bear in mind that if you subsequently wish to create an asset for a CI, it will need to be done manually. CIs in this instance will have the Requires verification field ticked. You can either choose to click the UI Actions  "Create Asset (no duplicate CI exists)" or "Merge CI" (duplicate CI exists)" on the CI form

If Asset tracking strategy on the Model linked to the CI is "Don't create assets", an Asset will not be created when the CI is created.

SAM Pro and HAM

With the advent of the Software Asset Management Professional product, ServiceNow completely overhauled the way software is represented, with Publisher, Product, Version and Edition making up a unique software model, entitlements and allocations supporting a licence position, and a content management service correlating discovery with software, largely rendering the Model Category irrelevant. However, Hardware Asset Management was less revolutionary in terms of data structures, as the standard asset management fulfils many use cases, and hardware by its nature still requires assessment of assets by device type, so Model Category is still useful. However, model normalization via the Content Service for hardware models provides a generally a more useful set of data for reporting than Model Category.

The Future

The Model Category table hasn't changed in quite a while, so it is inevitable to ponder whether the winds of change will blow in something to replace it in ServiceNow. At the moment I don't see any major changes coming, but with the advent of CSDM and the standardization of Lifecycle Stages and Statuses across the platform to support the foundational data, it's possible (but somewhat improbable in the short term, at least) that not only will the Model Category be superseded, but that Assets and CIs may once more be combined.