How Assets Are Automatically Created When a CI Is Inserted — Delayed (Queued) 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 the system property glide.create_alm_asset.async is set to "true", the Business Rule "Create Asset on insert" does not create assets at the time the CI is inserted. Instead, it evaluates whether the CI is eligible for asset creation and, if so, creates a queue record. A scheduled job running every 15 minutes then picks up the queued records and creates the actual assets. This article documents every decision gate in the delayed creation path, from the BR through the queue processing, traced directly from the BR script, the AssetandCI Script Include, and the AssetQueueProcessor Script Include. For the immediate creation path where this property is "false", refer to the companion article: KB2909484 1. BUSINESS RULE CONFIGURATION Name: Create Asset on insert Table: Configuration Item [cmdb_ci] When: Before Operation: Insert only This is the same BR used for immediate creation. The BR condition gates (asset pointer validation and class exclusion check via cmdb_business_rule_exclusions) are identical and are documented in the companion KB2909484. This article begins at the point where the BR script has already passed those condition checks. 2. PHASE 1 — WHAT HAPPENS AT CI INSERT TIME When glide.create_alm_asset.async is "true", the BR script enters the delayed branch and performs two steps: an eligibility check, and if eligible, a queue record insertion. GATE 1 — ELIGIBILITY CHECK (isAssetRequiredForCI) The BR calls a static method that determines whether the CI's class warrants asset creation. This is a lightweight check designed to avoid queuing CIs that would never get an asset. The method works as follows: Step A — Class-level check using an in-memory cache: The method maintains a map (modelCategoryCIClassMap) that caches whether a given sys_class_name is eligible. If the class has already been evaluated in this transaction, the cached result is returned immediately. If the class is not yet cached, the method queries cmdb_model_category for a record where cmdb_ci_class matches the CI's sys_class_name. If a matching record is found AND both the asset_class and cmdb_ci_class fields on the category are non-empty, the class is cached as eligible (true). If no matching category is found, or if either field is empty, the class is cached as ineligible (false). The cache has a safety cap: if it reaches 10,000 entries, it is reset to an empty object to prevent memory issues. If the class is ineligible, the method returns false and no queue record is created. Step B — Model-level tracking strategy check: If the class is eligible, the method then checks the CI's model. If the CI has a model assigned and the model's asset_tracking_strategy is "Do not track" or "Track as consumable", the method returns false — no queue record is created. If the CI has no model, or the model's strategy is "Leave to category" (or any other value), the method returns true. GATE 2 — QUEUE RECORD CREATION If the eligibility check returns true, the BR creates a new record in the alm_asset_creation_queue table with: source_id: The CI's sys_idtable: The CI's sys_class_namestate: Defaults to "ready" At this point, the BR script completes. No asset has been created yet. The CI is inserted into the database without an asset reference. The actual asset creation is handled by the scheduled job described below. 3. PHASE 2 — WHAT THE SCHEDULED JOB DOES Name: Asset - Create asset delayed sync Run: Periodically Repeat Interval: Every 15 minutes Application: Global Active: Yes Conditional: No STEP 1 — JOB LOGGING The job creates a log entry in the asset_job_log table, recording the job name, start time, and setting status to "in_progress". All processing outcomes are tracked and written to this log upon completion. STEP 2 — DUPLICATE JOB CHECK Before processing, the job checks whether another instance of the same job is already running. If yes, the job stops immediately and logs a failure: "[job name] job is already running." This prevents concurrent queue processing that could cause duplicate assets. STEP 3 — QUEUE PROCESSING If no duplicate is running, the job hands off to the AssetQueueProcessor, which processes queue records through the following sequence: A — BATCH RETRIEVAL The processor queries alm_asset_creation_queue for records where state = "ready", limited to 200 records per batch. If domain separation is active, only records in the current domain are retrieved. Processing continues in a loop: after each batch is fully processed, if the elapsed time is still within the timeout period, the next batch of 200 is fetched. This continues until either no more "ready" records exist or the timeout is reached. B — TIMEOUT PROTECTION The processor tracks how long it has been running. It will stop accepting new batches once the elapsed time exceeds the timeout period. The timeout defaults to 13 minutes, controlled by the property com.snc.asset_management.assetAsyncJob.timeoutPeriod (read from the asset_property table). The configurable range is 1 to 60 minutes. If the property is not set or is outside this range, the default of 13 minutes is used. Since the job runs every 15 minutes and the default timeout is 13 minutes, this provides a 2-minute buffer to prevent overlap with the next scheduled run. C — PER-RECORD PROCESSING For each queue record, the following gates are evaluated: GATE 3 — CI CLASS VALIDATION The processor validates that the table name stored in the queue record is a valid CI child class. It does this by walking the class hierarchy using TableUtils and confirming that cmdb_ci is an ancestor. Important: The base cmdb_ci class itself is explicitly excluded. The processor maintains a list of non-supported classes that starts with cmdb_ci. If the queue record's table is cmdb_ci or is not a CI class at all, it is counted as NOT_SUPPORTED. This is a gate that does not exist in the immediate creation path. With immediate creation, assets can be created for the base cmdb_ci class. With delayed creation, the base cmdb_ci class is explicitly excluded by the queue processor. GATE 4 — CI RECORD EXISTENCE CHECK The processor fetches the CI record by sys_id (from source_id on the queue record) using the table name from the queue record. If the CI no longer exists — for example, it was deleted between the time it was queued and the time the job runs — the record is counted as CI_DELETED. GATE 5 — ASSET CREATION (same core logic as immediate path) If the CI exists, the processor calls the same createAssetByPass method used in the immediate path, with one parameter difference: the bypass flag is set to true instead of false. However, this difference does not change the enforce_verification behavior. The condition for bypassing verification requires bypass to be true AND validateCIVerification to be false AND the CI's unverified flag to be true — all three together. Since validateCIVerification is true in both the immediate and delayed paths, the bypass clause does not activate. Therefore, if the model category has enforce_verification enabled, asset creation is skipped and the CI is marked as needing verification, exactly as in the immediate path. Where the bypass flag does matter is in field synchronization. When bypass is true, the field sync runs unconditionally — it copies all mapped field values from CI to asset regardless of whether the fields have "changed." This is necessary because in the delayed path, the CI was inserted minutes (or longer) ago, and the platform's change-tracking on fields is no longer meaningful. All other gates inside createAssetByPass are identical to the immediate creation path: duplicate asset check, model category resolution with auto-repair, tracking strategy check, orphan asset lookup, and enforce verification. Refer to the companion KB2909484 for detailed documentation of each gate. D — WHAT HAPPENS AFTER EACH RECORD ASSET_CREATED: Counter incremented. The CI is updated with a skip_sync flag to prevent the CI-to-asset sync Business Rule from firing redundantly. The queue record is deleted from alm_asset_creation_queue. ASSET_SKIPPED: Counter incremented. Queue record deleted. No CI update needed. CI_NEEDS_VERIFICATION: Counter incremented. The CI is updated (its unverified flag was set to true inside createAssetByPass). Queue record deleted. CI_ERROR: The queue record is NOT deleted. Its state is changed to "error" and the error message is written to the comments field on the queue record. The record remains in the queue for investigation. For all non-error outcomes, the queue record is removed after processing. Error records persist for troubleshooting. E — JOB COMPLETION AND LOGGING After all batches are processed (or the timeout is reached), the job log is finalized with: Status: "completed" or "failed" (if any record threw an unrecoverable error).Comments: A summary with counts for each outcome — TOTAL_RECORDS, ASSET_CREATED, ASSET_SKIPPED, CI_NEEDS_VERIFICATION, CI_DELETED, CI_ERROR, NOT_SUPPORTED. Job logs are retained in the asset_job_log table. Old logs are automatically cleaned up based on the property com.snc.asset_management.asset_job_log.deletionDays (default 60 days, configurable range 30-180 days). 4. DECISION FLOW SUMMARY Phase 1 — At CI insert time (Business Rule): Gate 1a — CI class has a matching cmdb_model_category with non-empty asset_class and cmdb_ci_class. Gate 1b — CI model's asset_tracking_strategy is not "Do not track" or "Track as consumable." Result — Queue record created in alm_asset_creation_queue with state "ready." Phase 2 — Scheduled job (every 15 minutes): Step 1 — Job checks for duplicate running instance. Stops if already running. Step 2 — Fetches up to 200 queue records in state "ready" per batch. Gate 3 — Queue record's table must be a valid CI child class (base cmdb_ci excluded). Gate 4 — CI record must still exist in the database. Gate 5 — Same gates as immediate path: duplicate check, model category resolution, tracking strategy, orphan asset lookup, enforce verification. Result — Asset created, fields synced from CI, CI updated with asset reference, queue record deleted. 5. KEY DIFFERENCES FROM IMMEDIATE CREATION Timing: Asset is not created at CI insert time. It is created when the scheduled job next runs (up to 15 minutes later, or longer if the queue has a large backlog). Base cmdb_ci class: Excluded in the delayed path. The queue processor explicitly skips records where the table is cmdb_ci. In the immediate path, there is no such exclusion. Field synchronization: In the delayed path, all mapped fields are synced unconditionally (bypass = true). In the immediate path, sync compares current values and only copies if they differ (bypass = false). This difference exists because change-tracking is not meaningful for records inserted minutes or hours earlier. Error handling: In the immediate path, if asset creation fails, the BR has no retry mechanism. In the delayed path, failed records remain in the queue with state "error" and can be investigated and reprocessed. Model repair: In both paths, the same model and model category auto-repair logic runs (assigning "Unknown" model, repairing missing category on model). However, in the delayed path this runs at job execution time, not at CI insert time — so any model/category changes made between insert and job execution are picked up. 6. KEY TABLES alm_asset_creation_queue — Queue table for deferred asset creation. Fields: source_id (CI sys_id), table (CI sys_class_name), state (ready/error), comments. asset_job_log — Logging table for scheduled job runs. Records job name, start/end time, duration, status, and outcome summary. asset_job_log_detail — Step-level detail logging for job execution. cmdb_model_category — Maps CI classes to asset classes (used in eligibility check and during creation). cmdb_model — Defines asset_tracking_strategy (used in eligibility check and during creation). alm_asset_ci_field_mapping — Field-level sync mappings between CI and asset. alm_asset_ci_state_mapping — Base CI state-to-asset state mappings. alm_hardware_state_mapping — Hardware CI state-to-asset state mappings. 7. KEY SYSTEM PROPERTIES glide.create_alm_asset.async — Must be "true" for the delayed path. Type: true | false. Default: false. com.snc.asset_management.assetAsyncJob.timeoutPeriod — Controls how long the queue processor runs per execution, in minutes. Default: 13. Range: 1-60. Read from the asset_property table. com.snc.asset_management.asset_job_log.deletionDays — Controls retention period for job logs in asset_job_log. Default: 60 days. Range: 30-180 days. 8. TROUBLESHOOTING NOTES Assets not being created after CI insert: Verify glide.create_alm_asset.async is "true". Check alm_asset_creation_queue for records in "ready" state. If queue records exist but no assets are being created, confirm the scheduled job "Asset - Create asset delayed sync" is active and running on schedule. Queue records stuck in "error" state: Open the error queue record and check the comments field for the specific error message. Common causes: asset already linked to another CI, asset insert failure due to mandatory field validation, or CI class not supported. Job log shows "job is already running": The previous execution did not complete within 15 minutes. This usually indicates a large queue backlog. Consider increasing the timeout via com.snc.asset_management.assetAsyncJob.timeoutPeriod (up to 60 minutes), but keep the value below the repeat interval to avoid overlap. Queue records counted as NOT_SUPPORTED: Expected for records where the table is the base cmdb_ci class. CIs must be in a child class (e.g., cmdb_ci_server, cmdb_ci_computer) for delayed asset creation to process them. CI_DELETED count is high: CIs were deleted between the time they were queued and the time the job ran. If this is frequent, investigate why CIs are being created and immediately deleted — the root cause is upstream of the asset creation process. Related Links<!-- /*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: ; } } How Assets Are Automatically Created When a CI Is Inserted — Immediate Creation