How Assets Are Automatically Created When a CI Is Inserted — Immediate CreationSummary<!-- /*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: ; } } When a Configuration Item (CI) record is inserted into the cmdb , the out-of-box Business Rule "Create Asset on insert" evaluates whether an asset record should be automatically created and bi-directionally linked to that CI. The system property glide.create_alm_asset.async controls the creation mode: When the value is "false", the asset is created immediately at the time the CI is created. This is the synchronous path documented in this article.When the value is "true", asset creation is deferred. The CI is queued and the asset is created later via the scheduled job "Asset - Create asset delayed sync". BUSINESS RULE Name: Create Asset on insert Table: Configuration Item [cmdb_ci] When: Before Operation: Insert only Because the BR is defined on cmdb_ci, it fires on insert of any record into cmdb_ci or any class that extends it (e.g., cmdb_ci_server, cmdb_ci_computer, cmdb_ci_linux_server, etc.) due to standard BR inheritance. GATE-BY-GATE EXECUTION FLOW The BR passes through a series of decision gates. If any gate fails, asset creation is skipped. Below is each gate in execution order. GATE 1 — BR CONDITION (evaluated before the script executes) The BR condition performs two checks: Check A — Asset pointer validation: The CI must either have no asset reference at all, OR if it does have an asset reference, that asset's CI field must point to a different CI (a mismatch). In practical terms, this means the BR proceeds only when the CI does not already have a correctly linked asset. Check B — Class exclusion check: The system checks whether the CI's class (sys_class_name) is listed in the cmdb_business_rule_exclusions table. This check walks up the entire class hierarchy — if the CI's own class is not excluded, it checks the parent class, then the grandparent, and so on up to cmdb_ci. If any class in the hierarchy has a record in the exclusion table, the BR does not run and no asset is created. Results are cached in memory for performance. If either check fails, the BR script does not execute at all. GATE 2 — SYNC vs. ASYNC ROUTING The first thing the script does is read the system property glide.create_alm_asset.async. If the value is "true" (exact string match), the BR takes the asynchronous path — it checks eligibility and creates a queue record in alm_asset_creation_queue for later processing by the scheduled job. This path is outside the scope of this article. If the value is "false", empty, or undefined, the BR takes the synchronous (immediate) path. It instantiates the AssetandCI Script Include and calls the createAsset method, passing the current CI record. All subsequent gates below apply to this path. GATE 3 — DUPLICATE ASSET CHECK If the CI's asset field is already populated at this point, the method exits immediately and logs "Duplicate asset generation prevented for CI [name]". No asset is created. On a fresh insert this field is typically empty, but this guard protects against scenarios where another process (data import, IRE, earlier BR) has already set the asset field. GATE 4 — MODEL CATEGORY RESOLUTION The system queries the cmdb_model_category table for a record where cmdb_ci_class matches the CI's sys_class_name. This is a critical gate — if no matching model category exists for the CI's class, asset creation is skipped entirely. When a matching model category is found, the system also inspects the CI's model association and performs auto-repair if needed: Scenario A — CI has no model assigned: The system automatically assigns an "Unknown" model. It searches for an existing cmdb_model record named "Unknown" that is associated with the matching model category and has the same manufacturer as the CI. If none exists with that manufacturer, it looks for one with a null manufacturer. If still none exists, it creates a new "Unknown" model record. The CI's model_id field is then set to this model. Scenario B — CI has a model, but the model has no category: The system repairs the model record by setting its cmdb_model_category to the matching category and updating the model. Scenario C — CI has a model that already has a category: No repair action is needed. Processing continues normally. GATE 5 — ASSET TRACKING STRATEGY CHECK The system reads the CI's model's asset_tracking_strategy field. If the strategy is set to "Do not track" or "Track as consumable", the asset is not created and the method exits with a skip status. Asset creation only proceeds when the strategy is "Leave to category" (the default value) or when no explicit strategy is set on the model. GATE 6 — ORPHAN ASSET LOOKUP Even though the CI's asset field is empty (passed Gate 3), there may be an existing asset record in alm_asset whose ci field already points to this CI's sys_id. This handles data inconsistency situations. If such an orphan asset is found: The system checks whether that asset is also linked to a different CI (another CI has its asset field pointing to this same asset). If yes: Returns an error — "Asset record is synced to other CI record. Unable to sync multiple CIs to an asset." No asset is created.If no: The CI's asset field is set to the existing orphan asset's sys_id, re-establishing the link. No new asset is created. GATE 7 — ENFORCE VERIFICATION CHECK The system checks the enforce_verification flag on the model category. If enforce_verification is true: The BR does NOT create an asset. Instead, it sets the CI's unverified field to true and returns a "CI needs verification" status. The CI must be manually verified before an asset will be created for it. If enforce_verification is false (or not set): This is the normal path. Asset creation proceeds to the next stage. Additionally, the model category's asset_class field must not be empty — it must define which asset table to use (e.g., alm_hardware, alm_asset). If asset_class is empty, asset creation is skipped. ASSET RECORD CREATION When all seven gates are passed, the system creates the asset record. Step 1 — Initialize the asset record: A new record is initialized on the table defined by the model category's asset_class field (for example, alm_hardware for hardware CIs, alm_asset for base assets). The asset's ci field is set to the CI's sys_id, and the asset's model_category field is set to the matching model category's sys_id. Step 2 — Synchronize shared fields from CI to Asset: The AssetAndCISynchronizer Script Include copies field values from the CI to the new asset. This synchronization has three components: (a) Field mappings: The system reads active records from the alm_asset_ci_field_mapping table. Each record defines a CI-side field and a corresponding asset-side field. For each active mapping, the CI field value is copied to the asset field. Each mapping can also have an optional condition (ci_mapping_condition) — an encoded query the CI must match for that particular mapping to apply. If the condition is blank, the mapping always applies. If the system property sn_itam_enable_cache_for_asset_ci_mapping is set to "true" and domain separation is not active, field mappings are read from a scoped cache instead of querying the table each time, improving performance. (b) Cost synchronization: During CI-to-asset creation, cost fields are not synced. The code treats cost fields as informational on the CI side and does not transfer them to the asset. (c) State synchronization: The system maps the CI's status fields to asset state and substatus using mapping tables: For hardware CIs (those extending cmdb_ci_hardware): The alm_hardware_state_mapping table is used to map hardware_status and hardware_substatus to the asset's install_status and substatus.For base CIs (non-hardware): The alm_asset_ci_state_mapping table is used to map the CI's install_status to the asset's install_status and substatus. The system filters for active mappings where the sync direction is "CI to Asset" or "Both", with "CI to Asset" taking priority. Step 3 — Set additional fields: The CI's unverified field is set to false (clearing any prior flag).The asset's skip_asset_pid flag is set to true, making Product Instance ID generation optional when the CI has no serial number. Step 4 — Insert the asset: The asset record is inserted into the database. Step 5 — Link the CI to the new asset: If the insert is successful, the CI's asset field is set to the new asset's sys_id. Because this is a "before" Business Rule, this value is written to the CI when the platform completes the CI insert — no separate CI update call is needed, which avoids unnecessary update overhead. If the insert fails, the method returns an error status with the message "Asset creation failed." Step 6 — Post-insert operations (briefly noted): After the asset is inserted and linked, two additional operations may execute depending on system configuration: CSDM lifecycle stage/status synchronization back from asset to CI (if Product Instance Sync is active), and Product Instance ID synchronization from asset to CI. These are conditional and depend on CSDM/PID2 enablement. Detailed analysis of these operations is outside the scope of this article. DECISION FLOW SUMMARY For quick reference, the complete gate sequence: Gate 1 — CI has no correctly linked asset AND CI class is not in cmdb_business_rule_exclusions (checked with class hierarchy inheritance). Gate 2 — Property glide.create_alm_asset.async is not "true" (synchronous/immediate path). Gate 3 — CI's asset field is nil (no duplicate). Gate 4 — A cmdb_model_category record exists for the CI's sys_class_name. Missing models are auto-repaired with "Unknown" model. Gate 5 — The CI model's asset_tracking_strategy is not "Do not track" or "Track as consumable". Gate 6 — No orphan asset already exists for this CI. If one does, it is re-linked rather than duplicated. Gate 7 — The model category's enforce_verification is not true, and asset_class is defined. Result — Asset record created on the appropriate asset table, fields synced from CI, bi-directional link established. KEY TABLES cmdb_business_rule_exclusions — CI classes excluded from this BR, checked with inheritance up the class hierarchy. cmdb_model_category — Maps CI classes to asset classes. Controls enforce_verification flag and asset_class. cmdb_model — Defines asset_tracking_strategy. Auto-repaired if category association is missing. alm_asset_ci_field_mapping — Defines active field-level mappings between CI and asset fields, with optional conditions. alm_asset_ci_state_mapping — Maps base CI install_status to asset state/substatus (and vice versa), with sync direction control. alm_hardware_state_mapping — Maps hardware CI status/substatus to asset state/substatus (and vice versa), with sync direction control. KEY SYSTEM PROPERTIES glide.create_alm_asset.async — Controls whether asset creation is immediate (false) or deferred via scheduled job (true). Default value is false. Type: true | false. sn_itam_enable_cache_for_asset_ci_mapping — When true, field and state mappings are read from scoped cache instead of direct table queries during synchronization. Only effective when domain separation is not active.