Ingest practice questions

Check the 'No-Delete' flag on the Discovery Schedule record.

Why wrong: The No-Delete flag prevents CIs from being deleted when they are missing from a discovery scan; it does not control attribute-level precedence.

Disable the 'Asset tag' field mapping in the IRE payload processor script.

Why wrong: Discovery does not use script mappings for core attributes; it uses pattern outputs processed by the IRE.

Set the cmdb_ci table to read-only for the Discovery integration user via ACLs.

Why wrong: Blocking the integration user entirely would stop Discovery from updating any server attributes, breaking automated monitoring.

RestMessageV2.execute()

Why wrong: RestMessageV2 is used to make outbound REST calls, not to process payloads through the IRE locally.

CMDBAPI.ingest()

Why wrong: CMDBAPI.ingest() is not a valid standard ServiceNow API name for IRE processing.

GlideRecord.insert()

Why wrong: GlideRecord.insert() bypasses the IRE entirely, risking duplicate records and data integrity issues.

Discovery schedules do not support ingesting IP addresses automatically.

Why wrong: Discovery automatically discovers and ingests IP addresses and network adapters as part of standard host profiling.

The cmdb_ci_ip_address table requires manual creation of records due to security restrictions.

Why wrong: Security rules do not restrict Discovery from creating IP address records when running with appropriate system credentials.

Data Source Precedence has marked IP addresses as read-only.

Why wrong: Data Source Precedence controls attribute-level updates, not the creation or association of related IP records.

Set the coalesce field on the Transform Map to point to the datastore ID.

Why wrong: Coalescing on a legacy Transform Map does not resolve nested object ingestion or establish CMDB relationships.

Flatten the JSON payload in a Business Rule before it reaches the Import Set table.

Why wrong: While possible, flattening via custom Business Rules defeats the purpose of RTE's built-in hierarchical parsing capabilities.

Create two separate import set tables and link them using a standard GlideRecord script in a Transform Map.

Why wrong: Standard Transform Maps do not leverage the IRE natively and lead to architectural anti-patterns in CSDM implementations.

Add a Business Rule on cmdb_ci that checks the sys_updated_by field and aborts updates from the third-party source.

Why wrong: Business rules can interfere with payload processing and are not the recommended framework mechanism compared to IRE Data Source Precedence.

Modify the Discovery schedule to run after the third-party integration job completes.

Why wrong: Job timing does not enforce precedence; if the lower-priority source runs last, it would still overwrite attributes without precedence rules.

Create an Access Control List (ACL) that restricts write access on the cmdb_ci_linux_server table for the third-party integration user.

Why wrong: ACLs block all updates and will cause the integration to fail entirely rather than gracefully handle precedence.

Modify the coalesce setting on the Transform Map to use serial number.

Why wrong: Using standard Transform Map coalesce bypasses the IRE, which is a bad practice in the CSDM and CMDB framework.

Enable 'Robust Transform Engine' on the data source properties.

Why wrong: While RTE can process data, it still requires IRE rules to be configured properly to avoid duplicates.

Create a Data Source Precedence rule for the import set.

Why wrong: Data Source Precedence dictates which discovery source wins attributes, not how records are matched during identification.

The Transform Map is missing mandatory field mappings.

Why wrong: This error is generated by the IRE engine itself, which operates independently of legacy Transform Maps unless called via RTE.

The target CI table has mandatory dictionary fields that are not populated by the form layout.

Why wrong: IRE errors regarding missing attributes refer specifically to identification rule definitions, not general dictionary mandatory flags.

The Discovery source name is invalid.

Why wrong: An invalid discovery source would generate a different tracking or source mapping error, not a missing identification attribute error.

In Robust Transform Engine (RTE) definitions, map the process table to the software installation table.

Why wrong: RTE is used for import sets, not for Service Mapping pattern execution.

In CI Class Manager, modify the Identification Rule for cmdb_ci_appl.

Why wrong: While cmdb_ci_appl holds application CIs, Service Mapping relies primarily on Application Patterns and Process Classifiers rather than standard CI Class Manager identification rules for process traversal.

In Data Source Precedence rules, set Discovery as the primary source for process tables.

Why wrong: Data Source Precedence does not resolve pattern traversal or process classification issues during Service Mapping.

Discovery Log Analyzer

Why wrong: While Discovery logs show execution steps, they do not provide an interactive payload simulation interface like the IRE test tool.

Transform Map Simulator

Why wrong: The Transform Map Simulator is for legacy import sets, not IRE-based payloads.

Service Mapping Workbench

Why wrong: Service Mapping Workbench is used specifically for building and troubleshooting service maps, not general CI payload testing.

Modify the IRE Identification Rule to automatically ignore whitespace.

Why wrong: IRE identification rules do not have built-in regex string manipulation parameters for trimming whitespace.

Write a Client Script on the target cmdb_ci table to strip whitespace upon insert.

Why wrong: Client scripts run in the browser during form interactions, not during backend batch data ingestion via import sets.

Configure a Data Policy to reject records containing whitespace.

Why wrong: Data policies reject invalid data rather than correcting or normalizing it, which would cause ingestion failures.

The IRE maps discovery sources based on IP address ranges rather than the discovery source string.

Why wrong: Discovery source matching relies on the designated 'discovery_source' field value passed in the payload.

The IRE automatically normalizes all discovery source strings to lowercase and strips special characters.

Why wrong: The IRE does not automatically alter or normalize discovery source strings; exact matching is required.

Discovery source names only affect reporting and have no impact on IRE reconciliation behavior.

Why wrong: Discovery source names are fundamental to tracking which source owns which attribute value under Data Source Precedence.

Check the System Log (syslog) for standard warning messages tagged with 'TransformMap'.

Why wrong: IRE errors do not always log under TransformMap syslog entries, especially when using robust transformers or direct script APIs.

Review the Email Notifications table for failed ingestion alerts.

Why wrong: ServiceNow does not send email notifications by default for silent IRE rejections unless custom alerts are configured.

Inspect the Discovery Status dashboard.

Why wrong: Discovery Status dashboards only track native Discovery schedules, not custom IntegrationHub REST imports.

The IRE will consider it a match if any single attribute matches the incoming payload.

Why wrong: An OR condition requires multiple distinct rule entries, whereas attributes within a single rule entry act as an AND condition.

The IRE will automatically merge records if any two attributes match.

Why wrong: Merging requires explicit duplicate remediation tasks or specific multi-match handling configurations, not standard compound matching.

Multiple attributes are only used for reporting and have no effect on CI identification.

Why wrong: Attributes in identification rules directly drive the matching logic of the IRE.

References to non-existent CIs are automatically converted into Incident records in IT Service Management.

Why wrong: CMDB ingestion mechanisms do not automatically generate ITSM incident records for payload reference failures.

The IRE automatically creates dummy placeholder records for any unresolving reference.

Why wrong: The IRE never creates unverified dummy records automatically; it either creates the referenced CI if valid payload data exists or rejects/ignores the invalid reference.

The entire payload is always aborted if any single related reference cannot be resolved immediately.

Why wrong: Depending on payload configuration, independent CI updates may succeed even if specific relationship links fail or require secondary processing.

In CI Class Manager under Discovery Source Precedence.

Why wrong: Data Source Precedence governs attribute updates, not target host authentication credentials.

In the CMDB Health Dashboard under Audit Rules.

Why wrong: CMDB Health measures quality metrics (completeness, correctness, compliance), not host connection credentials.

In the Robust Transform Engine source properties.

Why wrong: RTE is used for file/REST/JDBC import sets, not native Discovery credential management.

cmdb_health_result

Why wrong: cmdb_health_result stores the calculated scores for CMDB audit rules.

sys_import_set_row

Why wrong: sys_import_set_row stores raw staging data for import sets before transformation and ingestion.

cmdb_rel_ci

Why wrong: cmdb_rel_ci stores relationships between different CIs (e.g., Server runs on Datacenter), not data source associations.

Discovery is hardcoded to ignore any records created by Transform Maps.

Why wrong: Discovery does not ignore records based on creation method; it relies on IRE matching logic and identification rules.

The cmdb_ci table has a business rule that forces duplicate insertion for security purposes.

Why wrong: ServiceNow does not enforce duplicate insertion via security business rules on the base CI table.

Data Source Precedence rules were not set to 'Manual' before running Discovery.

Why wrong: Precedence rules dictate attribute overwriting, not initial CI identification matching.

Set the Import Set transform map property to 'Ignore Errors' globally.

Why wrong: Legacy transform map properties do not govern Robust Transform Engine execution flows.

Modify the IRE engine configuration property 'glide.cmdb.ire.abort_on_error' to false.

Why wrong: This property does not exist; IRE handles row errors natively based on payload and API invocation parameters.

Write a global Business Rule on sys_import_set_row to catch exceptions.

Why wrong: Business rules on import staging tables are inefficient and do not manage internal RTE stream errors.

Discovery -> Identification -> Classes

Why wrong: Discovery modules link to schedules and patterns, while identification rules reside within CI Class Manager.

Configuration -> CMDB Properties -> Rules

Why wrong: CMDB properties govern global settings, not class-specific identification rules.

System Definition -> Identification Rules

Why wrong: Identification rules are managed inside CI Class Manager, not as a standalone module under System Definition.

Use the Import Set Web Service table API directly.

Why wrong: While import set web services exist, invoking the IRE via script provides direct programmatic control over payload processing without staging table overhead.

Instantiate a GlideRecord on `cmdb_ci` and call `.insert()` for each item in the JSON body.

Why wrong: Direct `GlideRecord.insert()` bypasses the IRE and should be avoided for integrations.

Call `current.update()` after mapping the JSON properties to the request object.

Why wrong: `current.update()` is specific to business rules and record forms, not REST script inbound processing.