CMDB/ITAM Learning
Interactive simulators for ServiceNow ITAM/AMDB and CMDB. Real table and field names. Pick one and play!
ITAM/AMDB — IT Asset Management (HAM)
Models, assets, normalization, and the hardware lifecycle
Model Factory
Configure a model. Deploy a device. Watch what breaks.
A live assembly-line view of how a device becomes a Configuration Item in ServiceNow. Toggle the model category, change the product class, or remove a required field — the pipeline lights up green, amber, or red and tells you which downstream system just broke and why.
What it teaches
- cmdb_model_category → product class routing
- cmdb_hardware_product_model vs generic cmdb_model
- Asset / CI link creation via IRE
- HAM normalization and where it silently fails
Normalization Lab
Model in. Normalized model out. What changed and why.
Follow a cmdb_model record through the HAM normalization engine. Watch it match (or fail to match) against the product catalog, see the normalization status flip between Normalized, Not Normalizable, and Review, and trace what happens to the asset-to-model link when the original model gets remapped to a normalized record.
What it teaches
- Normalization statuses: Normalized, Not Normalizable, Review
- cmdb_model → cmdb_hardware_product_model remapping
- Asset model reference rebinding after normalization
- Impact on HAM reports and asset accuracy
Asset Lifecycle
9 install_status codes. 40 substatus pairings. One state machine.
Drive an alm_asset record through every OOB install_status — On order, In stock, In transit, In use, In maintenance, Retired, Missing, Consumed, Build — and pick from the exact substatus list each code allows. Every pairing is sourced from sys_choice.dependent_value on a live instance. Miss a required field and the transition is blocked.
What it teaches
- alm_asset.install_status: the 9 OOB integer codes
- substatus is a dependent choice — each install_status has its own list
- Required fields per state (assigned_to, stockroom, location)
- Pre-CSDM (install_status) vs Post-CSDM 4.0 (life_cycle_stage) vocabulary
CMDB — Configuration Management
Discovery, reconciliation, lifecycle stages, and CI relationships
IRE Factory
Two sources disagree. Set the rules. Watch who wins.
Two discovery sources push conflicting values for the same CI. You configure the IRE — set identification rules, define data source precedence, adjust reconciliation priorities, and watch the engine either converge or flap.
What it teaches
- IRE identification rules and matching criteria
- Data source precedence and priority ordering
- Reconciliation rules and conflict resolution
- Flapping detection and how to stop it
Asset ↔ CI Sync
One record changes. Does the other follow?
Modify fields on an alm_hardware record and watch which values propagate to the linked cmdb_ci — and which don't. Then do it in reverse. See exactly which fields are synced, which direction they flow, and what breaks the link entirely.
What it teaches
- alm_hardware ↔ cmdb_ci field synchronization rules
- Which fields are source-of-truth on which side
- What breaks the asset-to-CI reference link
- How disposal and retirement cascade across both records
CI Lifecycle
11 stages. 46 statuses. Zero foreign keys enforcing the pairing.
Walk a CI through all 11 OOB life_cycle_stage values — Ideation, Design, Purchase, Deploy, Inventory, Operational, End of Life, End of Operation, Missing, Defective, To Be Determined — and pick from the 46 life_cycle_stage_status values. Both fields are flat reference tables with no FK: the stage↔status grouping is a ServiceNow documentation convention, not enforced. Toggle the convention guard off and see what a 'valid' off-convention combo looks like.
What it teaches
- life_cycle_stage (11 rows) and life_cycle_stage_status (46 rows)
- Conventional status sets per stage (ServiceNow CSDM docs)
- Why the platform lets you pick any status with any stage
- How CSDM 4.0 vocabulary coexists with install_status (not replaces it)
ITAM/AMDB — IT Asset Management (SAM)
Software licensing, entitlements, normalization, and compliance