In modern ServiceNow implementations, especially within the Employee Center (ESC), search plays a critical role in improving user experience. Whether users are searching from the homepage or within specific sections like Support Resources, the results they see are not random — they are driven by a structured configuration called AI Search.
This article explains how search works behind the scenes, focusing on the hierarchy and configuration involved.
Where This Applies in Employee Center :
In Employee Center, search is available in multiple places:
- Global search (homepage search bar)
- Contextual search inside widgets like:
- Topic Content widget
- Support Resources → Search
For example, inside Browse Services → Support Resources, the search results are controlled by specific configurations:
- Search Application: ESC Portal Default Search Application
- Search Sources Filter: ESC Portal Knowledge Bases, ESC Portal Catalogs
AI Search Hierarchy :
1. Search Application:
The Search Application is the top-level configuration in AI Search and plays a key role in defining the overall search experience.
- It determines which search experience is used within a specific portal or widget, such as the Employee Center.
- It links to a Search Profile, which controls how search queries are interpreted and processed.
- It also defines which search sources are exposed to the users, thereby controlling what type of content appears in the results.
In simple terms, the Search Application acts as the entry point of the search experience, deciding how search behaves and what information is made available to the user.
Example : ESC Portal Default Search Application is the OOB one.
2. Search Profile :
The Search Profile acts as the central logic layer in AI Search, controlling how search queries are interpreted and how results are returned to the user.
- It defines which Search Sources are included, thereby deciding from which data sources (like Knowledge Bases or Catalog Items) the results should be fetched.
- It allows configuration of Synonyms, ensuring that different terms with similar meaning (for example, “VPN” and “Virtual Private Network”) return consistent results.
- It manages Stop words, which are common words that are ignored during search to improve relevance.
- It enables Typo handling, allowing the system to return correct results even when users enter misspelled queries.
- It controls Result ranking, ensuring that more relevant records (based on fields, weights, and conditions) appear higher in the search results.
- It supports Genius Results, which allow specific results to be promoted or highlighted for certain search queries.
In ServiceNow terms, the Search Profile acts as the logic layer that processes the user’s search query, applies configurations like synonyms, typo tolerance, and ranking rules, and then determines how results from different search sources should be combined and displayed to the user.
Example: ESC Portal Default Search Profile is the OOB one.
When this Search Profile is linked to a Search Application, its configured search sources are automatically reflected as facet buckets within that application.
- Synonyms
Synonyms allow different words with similar meaning to be treated the same during search. By default, ServiceNow provides a ‘Default Synonym Dictionary’ with common mappings (e.g., “VPN” and “Virtual Private Network”).
- Stop Words
Stop words are common words that are ignored during search to improve relevance. ServiceNow includes a ‘Default Stop Word Dictionary’ with words like “the” and “is”.
- Typo Handling
Typo handling ensures correct results even when users enter misspelled queries. It supports options like Spell Check, Synonym-based correction, and Stop Word handling, along with controls for case sensitivity, punctuation, and derived configurations using Indexed Sources.
- Genius Results
Genius Results allow specific records to be promoted for certain queries. You can configure them by defining the table, conditions, and keywords, so relevant results appear prominently.
3. Search Source :
The Search Source defines a specific category of content that can be searched in AI Search.
- It specifies the type of content being searched, such as Knowledge Articles or Catalog Items.
- It references an Indexed Source, which contains the actual data configuration.
- It can include conditions to filter which records should appear in search results.
In simple terms, it represents a category of searchable content, like Knowledge or Catalog.
- Example: ESC Portal Knowledge Bases, ESC Portal Catalogs
Each Search Source:
- Points to an Indexed Source for data retrieval.
- Applies additional filters to refine the results if required.
4. Indexed Source :
The Indexed Source is the most important layer in AI Search, as it defines the actual data that will be indexed and made searchable.
- It specifies the table from which records should be indexed, such as kb_knowledge for knowledge articles or sc_cat_item for catalog items.
- It allows you to define conditions not only on the main table but also on its child tables, ensuring that only relevant records are included in the search index.
- It provides configuration at the field level, where you decide how each field contributes to the search experience.
For field configuration:
- You can define whether a field should be searchable, meaning its content is considered when users perform a search.
- You can use mapping (map_to) to align fields with standard search attributes, ensuring consistent indexing and better relevance.
- You can control attributes such as not_searchable, to exclude fields from search, and display, to determine which fields are shown in the search results.
In simple terms, the Indexed Source acts as the data layer of AI Search, deciding what content is indexed, how it is filtered, and how it is presented to users during search.
How This Works in Employee Center
When a user searches in:
The widget uses:
- Search Application: ESC Portal Default
- Filtered Search Sources
Search Application calls:
→ Search Profile
Search Profile:
→ Fetches configured Search Sources
Search Sources:
→ Query their Indexed Sources
Indexed Sources:
→ Return filtered + relevant records
Creating AI Search Configuration (Step-by-Step)
Once the hierarchy of AI Search is understood, the next step is configuring it in the correct sequence. Although the structure starts with the Search Application at the top, the actual configuration begins from the foundational layer, which is the Search Profile. This approach ensures that all dependent components are properly defined before they are linked together.
Creating the Search Profile
The first step in setting up AI Search is to create a Search Profile. This profile acts as the central configuration that controls how search behaves, including how queries are interpreted and which sources are considered.
When a new Search Profile is created, it is initially saved in a draft (new) state. At this stage, it is not actively used by the system for search operations. By default, the profile is associated with standard configurations such as synonyms and stop words, which help improve the quality and accuracy of search results.
For the Search Profile to become active, it must be explicitly published. Only after publishing does the system start using it in search queries. It is also important to note that if any changes are made to a published profile, it automatically moves back into a draft state. These changes will not reflect in search results until the profile is published again. This controlled publishing mechanism ensures that updates do not unintentionally impact users without validation.
Once the profile is ready, the next step is to associate Search Sources with it. This can be done either by linking existing out-of-the-box search sources or by creating new ones, depending on the requirement.
If AI Search is Enabled you can see the Publish button and you can Publish the Search Profile.
Configuring the Indexed Source
Before creating a Search Source, it is essential to ensure that the corresponding Indexed Source is properly defined. The Indexed Source represents the actual data layer and determines what content is indexed and made searchable.
If the out-of-the-box Indexed Sources meet the requirement, they can be reused. However, in cases where specific filtering, field-level control, or customization is needed, a new Indexed Source should be created.
While configuring an Indexed Source, the primary step is selecting the appropriate table that contains the data to be searched. In addition to the table, conditions can be defined to restrict which records are included in the index. For example, only active or published records can be considered.
Another critical aspect of the Indexed Source is field configuration. Here, each field can be controlled individually to determine whether it should be searchable, displayed, or used for ranking. Attributes such as non-searchable fields, mapping configurations, and relevance adjustments can be applied. This level of control ensures that search results are both accurate and meaningful.
*Only one Indexed Source for one Table
Creating the Search Source
Once the Indexed Source is ready, the next step is to create the Search Source. The Search Source acts as an intermediate layer that connects the Search Profile with the Indexed Source. It represents a logical grouping of content, such as knowledge articles or catalog items.
During the creation of a Search Source, the previously configured Indexed Source must be selected. Additional conditions can also be applied at this level if further filtering is required. This allows more granular control over what subset of the indexed data should be exposed through this particular source.
It is important to ensure that the mapping between the Search Source and the Indexed Source is correct. If these are created separately, they must be explicitly linked; otherwise, the data will not appear in search results. After creation, the Search Source must be added to the relevant Search Profile to make it part of the search experience.
Creating the Search Application
The final step in the configuration process is creating the Search Application. This is the layer that brings together all the previously defined components and makes them available to the end users.
While creating the Search Application, the most important configuration is linking the appropriate Search Profile. Once the profile is attached, all associated Search Sources automatically become part of the Search Application and are displayed as facet buckets or filters in the search interface.
It is important to understand that the Search Application does not define search logic itself. Instead, it serves as a presentation layer that exposes the configurations defined in the Search Profile. This separation of concerns allows flexibility in managing search behaviour independently from how it is presented in the user interface.
In most implementations, it is recommended to clone an existing out-of-the-box Search Application rather than creating one entirely from scratch. Cloning ensures that standard configurations and dependencies are retained, reducing the risk of missing critical settings. However, if the requirement is highly customized, a new Search Application can also be created and configured accordingly.
End-to-End Configuration Flow
The configuration follows a clear sequence. The Search Profile is created and published first, as it defines the core behaviour. Indexed Sources are then configured to determine what data is searchable, followed by creating Search Sources to link that data to the profile. Finally, the Search Application is set up to expose everything to the end user.
Important Considerations
If results are not appearing as expected, check whether the Search Profile is published, the Search Sources are properly linked, and the Indexed Source conditions are not filtering out records. Ensuring each layer is correctly configured and connected is essential for accurate search results.
