Adding CMDB Computers to AI Search

Note: A ready-to-import update set containing the configuration from this article is available to download at the bottom of the post.

One of the limitations I ran into while moving ServiceNow’s global search over to AI Search for Next Experience was CMDB data.

By default, ServiceNow doesn’t allow CMDB tables such as cmdb_ci_computer to be configured as AI Search Indexed Sources. This was a fairly significant limitation for us, as being able to search for a computer by hostname or other identifying information is something our IT staff regularly do from the global search.

It turns out there is a way around it.

Allowing CMDB tables to be indexed

There is an undocumented system property which allows a normally excluded table to be used as an AI Search indexed source:

glide.ais.ingestion.should_index

For computers, set the value to:

cmdb_ci_computer

The property is a String property in the Global scope. In my implementation I’ve described it as:

AI Search ingestion override used to allow selected tables to be configured as AI Search indexed sources.

Once the property exists, cmdb_ci_computer can be selected when creating an AI Search Indexed Source.

Creating the indexed source

I created an indexed source called Computers, using cmdb_ci_computer as the source table.

I didn’t want to index every computer that had ever existed in the CMDB, so I added a filter to only include machines discovered within the last 12 months:

Last discovered is on Last 12 months

I’ve also disabled attachment indexing for this source.

After creating the indexed source, I created an AI Search Search Source for Computers and added it to the Next Experience Search Configuration profile.

I also created a source facet so users can filter the results to Computer records from the search results page.

At this point, searching for a computer worked — but there was another problem.

Fixing the search result display

The first time I searched for a hostname, AI Search returned a result, but the card was effectively blank. It just displayed the generic result type without a useful title.

The normal Generic EVAM template expects AI Search fields such as ai_search_teaser_title. Those weren’t being populated in a useful way for the computer record.

To fix this, I created a new EVAM View Template called:

AI Search Global | Computers

and based it on the normal AI Search result card.

The important difference is that the title is mapped directly to the computer’s name field:

{
    "component": "sn-search-result-evam-card",
    "staticValues": {
        "imageType": {
            "translatable": false,
            "key": "icon"
        },
        "icon": {
            "translatable": false,
            "key": "laptop-outline"
        },
        "textHeaderLabelOne": {
            "translatable": true,
            "key": "Computer"
        },
        "detailLabelOne": {
            "translatable": true,
            "key": "Assigned to:"
        },
        "detailLabelTwo": {
            "translatable": true,
            "key": "Serial number:"
        },
        "detailLabelThree": {
            "translatable": true,
            "key": "Model:"
        },
        "detailLabelFour": {
            "translatable": true,
            "key": "Location:"
        },
        "detailLabelSeparator": {
            "translatable": false,
            "key": " | "
        }
    },
    "mappings": {
        "title": "name",
        "summary": "ai_search_teaser_text",
        "detailValueOne": "assigned_to",
        "detailValueTwo": "serial_number",
        "detailValueThree": "model_id",
        "detailValueFour": "location"
    },
    "actionMappings": {
        "clickAction": "navigation"
    }
}

This uses the Horizon laptop-outline icon and displays useful CI information including the assigned user, serial number, model and location.

Adding the EVAM View Config

The template then needs an EVAM View Config so that AI Search knows to use it for records from cmdb_ci_computer.

Mine is called AI Search Global | Computer, with the table set to cmdb_ci_computer and an order of 100.

The following table fields are exposed to the template:

name
assigned_to
serial_number
model_id
location

and the custom fields are:

ai_search_teaser_title
ai_search_teaser_text
navigation_url

The view config is added to the existing AI Search For Next Experience Bundle, and the standard navigation declarative action is linked so clicking the search result opens the CI.

The end result is a normal-looking AI Search result showing the computer name and useful information such as the assigned user, serial number, model and location.

More importantly, it means computer records are once again available from the global search when using AI Search for Next Experience.

A word of caution

glide.ais.ingestion.should_index does not appear to be a documented, customer-facing ServiceNow property.

It has been mentioned as a solution on the ServiceNow Community, including by ServiceNow employees, but the official documentation still describes CMDB-derived tables as excluded from normal AI Search indexing.

Because of that, I’d treat this as an undocumented workaround rather than a fully supported feature.

I’d also strongly recommend against simply indexing the whole CMDB. Limit the indexed source to the CI class you actually need and use an appropriate filter to avoid filling the index with stale records.

In my case, I’m only indexing cmdb_ci_computer and only computers discovered within the previous 12 months.

As always with undocumented platform behaviour, test it thoroughly and revisit it after upgrades.

Update set

I’ve created an update set containing the configuration described above, including:

  • the glide.ais.ingestion.should_index system property
  • the Computers indexed source
  • the AI Search search source and profile relationship
  • the Computer search facet
  • the custom Computer EVAM template
  • the Computer EVAM View Config and navigation action

Download the update set

The update set was built for AI Search for Next Experience, so review the records carefully before committing it to your own instance.

Sources and further reading