Asset Lifecycle

Drive an alm_hardware record through the 9 OOB install_status codes and every dependent substatus. Set required fields and watch the state machine respond.

Table

CSDM era

Asset Fields

assigned_toRequired for In Use

stockroomRequired for In Stock

locationRequired for In Transit, In Use

substatusOptional for next transition

Ignored if not valid for the chosen target state.

Current State

alm_hardware.install_status

On order

Linked CI

Linked — on_order

alm_hardware.install_status · substatus9 OOB codes · ~40 dependent substatus pairings

Audit Trail

No transitions yet. Click a valid state to begin.

Asset Lifecycle Cheatsheet

Asset-side lifecycle fields across the two tables the lab touches. Each field is tagged with the CSDM era it belongs to — CSDM 4+ was added in CSDM 4.0 to unify asset + CI lifecycle under one vocabulary (still current in CSDM 5.0); Pre CSDM 4.0 is the traditional vocabulary, still in active use — not deprecated. alm_hardware extends alm_asset, so every field defined on the parent is visible on the child via table inheritance — shown as “inherited” cells.

Field	`alm_asset` Asset parent table — all asset-side lifecycle fields are defined here	`alm_hardware` Hardware asset (HAM) — inherits everything from alm_asset
`life_cycle_stage`	✓CSDM 4+Reference → life_cycle_stage CSDM 4.0+ unified lifecycle stage, added alongside install_status (does NOT replace it). Free reference field — no OOB state machine, no required-field rules. Real column name uses underscores: life_cycle_stage. Ideation, Design, Purchase, Deploy, Inventory, Operational, End of Life, End of Operation, Missing, Defective, To Be Determined (11 OOB rows)	✓CSDM 4+Reference → life_cycle_stage Inherited from alm_asset.life_cycle_stage. Same reference target. Operational, Inventory, End of Life, etc.
`life_cycle_stage_status`	✓CSDM 4+Reference → life_cycle_stage_status CSDM 4.0+ granular status within a stage. Also a free reference — the stage↔status grouping is a ServiceNow documentation convention, NOT an enforced FK in the reference table itself. Available, In Stock, In Use, Retired, Disposed, Pending Repair, Pending Retirement, End of Support, Lost, Stolen (46 OOB rows total)	✓CSDM 4+Reference → life_cycle_stage_status Inherited from alm_asset.life_cycle_stage_status. Same reference target. In Use, In Stock, Retired, Pending Disposal, etc.
`install_status`	✓Pre CSDM 4.0Choice (integer) Primary asset lifecycle state. This is the field this lab's state machine is built on. Inherited by alm_hardware and all other alm_* child tables. On order (2), In stock (6), In transit (9), In use (1), Consumed (10), In maintenance (3), Retired (7), Missing (8), Build (11)	✓Pre CSDM 4.0Choice (integer) Exposed on alm_hardware via table inheritance — same choice list as alm_asset.install_status. No separate sys_choice rows. On order (2), In stock (6), In transit (9), In use (1), Consumed (10), In maintenance (3), Retired (7), Missing (8), Build (11)
`substatus`	✓Pre CSDM 4.0Choice (string, dependent) Sub-qualifier that varies with install_status via sys_choice.dependent_value. Each install_status code has its own valid substatus list — there are 40 (value,dependent_value) rows across all pairings OOB. In stock → Available, Reserved, Pending Repair, Pre-allocated… Retired → Disposed, Sold, Donated, Obsolete… Missing → Lost, Stolen	✓Pre CSDM 4.0Choice (string, dependent) Inherited from alm_asset.substatus. Same 40 dependent choice rows. Same as alm_asset — Available, Pending install, Disposed, Lost, Stolen, etc.

Table and field names (alm_asset, alm_hardware, cmdb_ci, install_status, substatus, life_cycle_stage, life_cycle_stage_status) are real ServiceNow columns. The 9 install_status codes and every substatus↔install_status pairing are pulled directly from OOB sys_choice (via dependent_value); the 11 stages / 46 statuses are pulled from the CSDM 4.0 reference tables on a dev instance. Stage↔status groupings are a ServiceNow documentation convention — the underlying reference tables are flat, with no foreign key between them. Transition rules are representative patterns ServiceNow does not enforce a hard state machine on alm_asset — your instance's Business Rules may differ. Learning tool, not a replacement for the platform.