Principal Classes and CI Life Cycle

What it is

A principal class is a CI class that agents should be able to pick on task forms. When principal classes are defined, the Configuration item field on records such as incidents and problems offers only CIs from those classes, instead of every disk, process and network adapter in the CMDB.

CI life cycle attributes record where a CI is in its life. CSDM standardizes them as two fields, Life Cycle Stage and Life Cycle Stage Status, and the platform keeps them aligned between a CI, its related asset and the legacy status fields.

How it works

Defining principal classes

You mark principal classes in CI Class Manager: open the class, select the principal class option and save. The flag is stored in the CMDB Class Information [cmdb_class_info] table.

Key behavior:

• No classes are principal by default. Until you mark some, the CI field is not filtered.
• The flag does not inherit. Marking Computer does not make Server or Personal Computer principal; each class must be marked on its own.
• The filter applies to the task tables named in a system property, com.snc.task.principal_class_filter, which lists the tables whose CI field uses the filter.
• A customized reference qualifier on the CI field can change the result, so a customized field may not show the filtering.

Choosing which classes

Choose classes that agents report problems against and that changes are raised for. ServiceNow guidance favors classes that are stable, well understood and directly affect business operations, starting with core infrastructure. A common start is a small set such as servers, databases and network devices, then growing it.

The flag changes what agents can select, not what the CMDB stores; component CIs keep their relationships for impact analysis.

Life cycle attributes under CSDM

Older data uses several status fields, such as Install Status and Operational Status on CIs and State and Substate on assets. CSDM replaces this mix with one value pair:

A life cycle control defines which stage and status combinations are valid for each class, and is the authority for what a mapping may set.

Mapping legacy values

The Life Cycle Mapping module, under CSDM, converts legacy status values into stage and status pairs, using the life_cycle_mapping table. The base system ships it with mappings for widely used legacy values, which you can edit or extend.

• If no rule matches, both fields are set to TBD.
• Legacy field values are not deleted after mapping.
• Once mapping errors are fixed, a scheduled job performs a one time bulk alignment of CI and asset records.
• Before bulk alignment, a discrepancy check must pass: every mapping must be active and assigned a life cycle control.

Keeping CIs and assets aligned

A hardware CI and its asset describe the same device, so their life cycle values must agree. The Enable life cycle sync option on the Life Cycle Mapping page turns on ongoing synchronization by setting the property csdm.lifecycle.sync.between.ci.and.asset.activated.

After it is enabled:

• Stage and status pairs sync in both directions between the asset and the CI.
• Legacy asset and CI values also keep syncing with each other.
• Changes to CI legacy values no longer update the CI's life cycle fields, so the CSDM pair becomes the field to maintain.
• A CSDM dashboard report lists CIs whose values have diverged.

Reviewing mappings and enabling sync needs itil_admin or asset_admin.

How the exam asks about this

• "Agents see disks and processes in the incident CI field." Mark the right classes as principal classes in CI Class Manager.
• "Server is principal, but Linux Server CIs do not appear." The flag does not inherit; mark the child class too.
• "A retired asset still shows its CI as operational." Map legacy values and enable life cycle sync so stage and status stay aligned between asset and CI.