Understanding Life Cycle Control Inheritance Across CMDB Class Hierarchies<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } .kb-wrapper { font-family: Lato, sans-serif; font-size: 12pt; line-height: 1.7; color: #000000; max-width: 100%; } .kb-wrapper h2 { font-family: Lato, sans-serif; font-size: 14pt; font-weight: 900; color: #032D42; border-bottom: 2px solid #e8fce4; padding-bottom: 6px; margin-top: 28px; margin-bottom: 14px; } .kb-wrapper p { font-family: Lato, sans-serif; font-size: 12pt; margin-bottom: 12px; } .kb-wrapper ul, .kb-wrapper ol { font-family: Lato, sans-serif; font-size: 12pt; margin-bottom: 12px; padding-left: 24px; } .kb-wrapper li { margin-bottom: 6px; } .kb-wrapper code { background: #e6f0f5; color: #032D42; border: 1px solid #b8cfd8; border-radius: 3px; padding: 1px 5px; font-size: 11pt; } .kb-wrapper .callout-info { border-left: 4px solid #52B8FF; background: #e6f4ff; padding: 12px 16px; margin: 16px 0; border-radius: 0 4px 4px 0; } .kb-wrapper .callout-info strong { color: #032D42; } .kb-wrapper .callout-warning { border-left: 4px solid #e6a817; background: #fff4e0; padding: 12px 16px; margin: 16px 0; border-radius: 0 4px 4px 0; } .kb-wrapper .callout-warning strong { color: #032D42; } .kb-wrapper table { width: 100%; border-collapse: collapse; margin: 16px 0; font-size: 12pt; } .kb-wrapper table th { background: #032D42; color: #ffffff; padding: 10px 14px; text-align: left; font-weight: 700; } .kb-wrapper table td { padding: 10px 14px; border-bottom: 1px solid #ddd; } .kb-wrapper table tr:nth-child(even) td { background: #e8fce4; } .kb-wrapper a { color: #032D42; text-decoration: underline; } .kb-wrapper .related-links { margin-top: 20px; } .kb-wrapper .related-links .disclaimer { font-size: 10pt; font-style: italic; margin-top: 2px; margin-bottom: 10px; } Summary Life Cycle Controls in the Configuration Management Database (CMDB) are defined at the table level. Each CMDB class inherits Life Cycle Controls from its parent table in the class hierarchy. This means that a subclass may have a different set of available Life Cycle Controls depending on which parent class it extends. Customers may observe that certain CI classes have fewer Life Cycle Control options than others, even when both classes appear to represent similar types of configuration items. This is expected behavior and is determined by the table inheritance model, not by the individual CI record. How Life Cycle Control Inheritance Works Life Cycle Controls govern the valid combinations of Life Cycle Stage and Life Cycle Stage Status for CIs stored in a given table. These controls are defined on a per-table basis in the life_cycle_control table and are inherited downward through the class hierarchy. The key points to understand are: Controls defined on a parent table are inherited by all child tables beneath it in the hierarchy.Some intermediate tables, such as the Hardware table (cmdb_ci_hardware), have their own dedicated set of Life Cycle Controls that provide additional stage and status options beyond what is available on the base Configuration Item (cmdb_ci) table.A child class inherits controls from its direct parent — not from sibling or cousin tables elsewhere in the hierarchy. Example: A class that extends cmdb_ci_hardware inherits all of the Life Cycle Controls defined for the Hardware table, which may include controls for stages such as Inventory, Pre-Production, Production, and Retirement. A different class that extends cmdb_ci directly will only inherit the more limited set of controls defined at the base Configuration Item level. Why Some Classes Have Fewer Options If a CI class extends the base cmdb_ci table rather than a more specific intermediate table like cmdb_ci_hardware, it will only have access to the Life Cycle Controls defined at the cmdb_ci level. This is by design. Not all CI classes represent the same type of asset or infrastructure component. Classes intended for non-IT or facility-related infrastructure, for example, may extend the base CI table directly and are intentionally excluded from hardware-specific lifecycle definitions. Important: Life Cycle Controls are managed at the platform level. ServiceNow does not support creating custom life cycle stage and status-to-table relationships outside of the delivered controls. Refer to your platform documentation for the supported configuration options. How to Identify Which Controls Apply to a Class To determine which Life Cycle Controls are available for a specific CI class: Navigate to Life Cycle Controls (life_cycle_control.list).Filter the Table column to the class you are investigating.Review the listed controls — these represent the valid Life Cycle Stage and Status combinations for that table and all of its child classes.If the list appears limited, check the parent class in the table hierarchy. The controls are likely inherited from a higher-level table that does not include the additional definitions found on other branches of the hierarchy (such as Hardware). Related Links CMDB CI lifecycle management Life cycle standard values