Global Text Search

What It Is

Global Text Search is ServiceNow's unified search mechanism that allows users to query across multiple tables simultaneously through the search bar in the application header. Unlike basic database queries that target specific tables, Global Text Search leverages Apache Lucene indexing to provide fast, relevance-ranked results from diverse record types including incidents, requests, knowledge articles, users, and configuration items. The search indexes are maintained separately from the database tables themselves, creating a parallel data structure optimized for text retrieval rather than transactional operations.

Architecturally, Global Text Search sits in the presentation layer of the ServiceNow platform, but depends heavily on background processing services that maintain the Lucene indexes. This creates a separation between what users search (the indexes) and what they ultimately interact with (the actual database records). The search capability is not a simple database feature—it's a complete indexing and retrieval system that requires ongoing maintenance, configuration, and understanding of how text analysis and tokenization work. When users type in the global search bar, they're querying pre-built indexes rather than performing live database searches, which is why search results can sometimes feel disconnected from the current state of records.

The business function Global Text Search serves is critical in large ITSM implementations where users need to find information across organizational silos without knowing exactly which table or module contains what they're looking for. A service desk agent searching for 'printer issues' needs to find relevant incidents, knowledge articles, and potentially related configuration items—all from different tables with different access controls and different field structures. Without cross-table search capability, users resort to opening multiple modules, running separate filtered lists, and manually correlating information, which destroys productivity and increases case resolution times. Global Text Search transforms ServiceNow from a collection of separate applications into a unified information discovery platform.

ServiceNow built Global Text Search using Lucene because relational database full-text search capabilities were insufficient for the platform's multi-tenant, multi-table architecture. Traditional database text search works well for single-table queries but becomes unwieldy when searching across dozens of tables with different schemas, access controls, and data types. Lucene provides document-based indexing that can flatten complex relational data into searchable text documents, apply sophisticated text analysis, and return relevance-ranked results. The alternative—running SQL LIKE queries across multiple tables in real-time—would create unacceptable performance overhead and couldn't provide the fuzzy matching and relevance scoring that users expect from modern search interfaces.

End users interact with Global Text Search through the simple search bar, but their experience depends entirely on configuration decisions made by administrators and developers. Users expect Google-like search behavior—type anything, get relevant results—but actually receive results determined by which tables are included in search groups, which fields are indexed, and how search sources are configured. System administrators configure Search Groups to determine which tables appear in results and Search Sources to control which fields from each table get indexed. Developers often need to customize search behavior through search processors, modify indexing logic, or troubleshoot why certain records don't appear in results. Process owners care about search because it affects how quickly their teams can find and act on information, but they rarely understand why search results vary or how to influence search relevance.

If Global Text Search didn't exist, ServiceNow would revert to being a collection of separate applications rather than an integrated platform. Users would be forced to search within individual modules, which works fine if you know exactly what type of record you're looking for but fails completely for cross-functional workflows. Service desk agents wouldn't be able to quickly search for all information related to a particular user or asset. Knowledge management would be siloed within the knowledge base rather than discoverable alongside operational records. The platform's value proposition as a single system of record would collapse because information discovery would require users to understand the underlying data model and navigate between disconnected interfaces.

Where It Fits in the Platform

Global Text Search operates at the intersection of ServiceNow's data layer, processing layer, and presentation layer. The actual search indexes live outside the main database as Lucene documents, but they're populated by background jobs that read from database tables. When users search, the platform queries the Lucene indexes first, then fetches the actual database records for display, applying security filters and field-level access controls in real-time. This architecture means search performance is largely independent of database performance, but it also creates complexity around data consistency and security.

The search system integrates deeply with ServiceNow's security model, applying domain separation, role-based access controls, and field-level security to search results. However, this security filtering happens after the initial search query, not during index creation, which creates important implications for search performance and result ranking. Search results are also influenced by the platform's internationalization features, with text analysis and tokenization varying by language, and by the workflow and approval systems that determine which records are actually accessible to users at any given time.

Key Relationships

• Search Groups (ts_search_group) — Define which tables participate in global search and control the grouping and ordering of search results.
• Search Sources (ts_search_source) — Specify which fields from each table get indexed and how they're weighted for relevance scoring.
• Access Controls (ACLs) — Filter search results based on user permissions, but this filtering occurs after the initial search query, affecting performance and result relevance.
• Scheduled Jobs — Background processes that rebuild and maintain the Lucene indexes, typically running during off-peak hours to minimize performance impact.
• Domain Separation — Restricts search results based on user domain access, but domains must be explicitly configured in search sources to work properly.
• Knowledge Management — Heavily dependent on global search for content discovery, with knowledge articles often configured as the highest-priority search results.

How You Encounter This in Practice

Search Results Don't Match Database Queries

You're a ServiceNow developer debugging why users can't find specific incident records through global search, even though the records clearly exist when you query the incident table directly. Users search for incident numbers like 'INC0123456' and get no results, but the same incident appears immediately when you navigate to the incidents list and filter by number. You discover that the search index hasn't been updated in three days due to a failed scheduled job, so recently created incidents exist in the database but not in the Lucene index that global search queries.

Understanding Global Text Search reveals that search results and database contents can be out of sync, and that search indexing is a separate process from record creation. This knowledge helps you troubleshoot search issues by checking index rebuild status, examining scheduled job logs, and understanding when manual index rebuilds are necessary. Without this understanding, developers often waste time debugging database queries, ACL configurations, or application logic when the real issue is index maintenance.

Custom Table Records Never Appear in Search

You're a ServiceNow administrator who created a custom table for tracking vendor contracts, populated it with hundreds of records, and configured proper ACLs and UI policies. End users complain that they can't find contract information through global search, even though they can access the records directly through the custom application menu. You initially assume this is a security or configuration issue with the custom table, but searching for contract numbers, vendor names, or contract terms returns no results while searching for incident numbers works perfectly.

Understanding Global Text Search shows you that custom tables don't automatically participate in global search—they must be explicitly added to Search Groups and configured with Search Sources that define which fields get indexed. This knowledge directs you to the ts_search_group and ts_search_source tables where you need to create configuration records. Without this understanding, administrators often spend time troubleshooting table permissions, field configurations, or user roles when the issue is simply that the table isn't included in search indexing.

Search Performance Degrades After Go-Live

You're a ServiceNow architect supporting a large enterprise implementation where global search worked perfectly during development and testing, but became unacceptably slow after go-live with real user volumes and data. Search queries that returned results in under two seconds during testing now take 15-30 seconds, and users are abandoning search in favor of navigating directly to specific modules. The database performance is fine, and individual table queries are fast, but global search has become a bottleneck that's affecting overall user adoption.

Understanding Global Text Search reveals that search performance depends not just on index size, but on how many tables are included in search groups, how security filtering is applied to results, and how search sources are configured. This knowledge helps you optimize search by reducing the number of indexed tables, adjusting field weighting, and understanding how domain separation and ACL filtering affect search query execution. Without this understanding, architects often try to solve search performance issues through database optimization or hardware scaling when the real solution requires search configuration tuning.

What People Get Wrong

Global Text Search results come from Lucene indexes that are updated through scheduled background jobs, not from real-time database queries. When a user updates an incident record, those changes don't immediately appear in global search results because the search index hasn't been rebuilt yet. The frequency of index updates depends on the scheduled job configuration, which typically runs during off-peak hours to minimize performance impact. This creates a window—sometimes hours long—where database records and search results are out of sync.

This misconception exists because users expect search to behave like Google, where results feel immediate and current. In ServiceNow development and test environments with low data volumes, index rebuilds often happen quickly enough that the delay isn't noticeable. However, in production environments with millions of records, full index rebuilds can take hours, making the gap between database state and search results very apparent. Users report 'missing' records that actually exist, or find outdated information in search results that no longer matches the current record state.

When administrators don't understand this delay, they often try to solve search issues by adjusting ACLs, modifying table configurations, or creating business rules to 'fix' search behavior. These changes don't address the real issue and can create additional problems. In production, this misunderstanding leads to help desk tickets about 'broken search' that are actually working as designed. Critical business processes that depend on finding recently created or updated records through search can fail during the window between database updates and index rebuilds.

The consequences compound in high-velocity environments like major incident management, where new information is constantly being added to incident records, but search results lag behind the current state. Service desk agents searching for recent updates or related incidents get incomplete results, leading to duplicated work and missed correlations between related issues.

Search security filtering happens at query time, not during index creation. The Lucene indexes contain data from all records that match the search source configuration, regardless of individual user permissions. When a user performs a search, ServiceNow first queries the Lucene index to get potential results, then applies ACL filtering, domain separation, and field-level security to determine what the user can actually see. This means the search index itself contains data that many users aren't authorized to access—security is enforced by filtering results, not by excluding data from the index.

This misconception arises because administrators assume search works like database queries, where security filtering can happen at the data access level. The reality is more complex: search indexes are essentially denormalized copies of database content, and applying security filters during index creation would require maintaining separate indexes for every possible combination of user permissions. Instead, ServiceNow creates comprehensive indexes and filters results dynamically based on the searching user's permissions.

This creates several production issues when administrators don't understand the architecture. Search performance degrades with complex security models because every search query triggers real-time ACL evaluation on potential results. Search result rankings can seem inconsistent because high-relevance matches might be filtered out due to security restrictions, promoting lower-relevance results that the user can access. Most critically, administrators might inadvertently create search configurations that expose sensitive data in index files or logs, assuming that search security works the same way as table security.

Admin vs Developer Perspective

For Admins

Admins own the search experience through configuring Search Groups and Search Sources, determining which tables appear in results and in what order. They manage the balance between search performance and result completeness by controlling which tables are indexed and how frequently indexes rebuild. The critical decision is choosing appropriate search sources for each group—including too many tables slows search performance while excluding important tables frustrates users. Admins also troubleshoot search issues by monitoring the ts_index_entry table for indexing failures and understanding why certain records don't appear in results.

For Developers

Developers rarely interact with Global Text Search programmatically since it's primarily a UI-driven feature, but they need to understand how their customizations affect search behavior. Custom fields added to searchable tables automatically become part of the search index, potentially exposing sensitive data or creating performance issues. When building custom applications, developers should consider whether their new tables need to be searchable and work with admins to configure appropriate search sources. The GlideTextSearchUtility server-side API provides limited programmatic access, but most search functionality remains tied to the platform's built-in indexing system rather than custom scripting.

How It Connects to Other Concepts

• Text Search Configuration — the underlying indexing system that Global Text Search depends on for its Lucene-based search capabilities. The ts_config table defines which fields are searchable and how they're weighted, directly affecting what Global Text Search can find and how results are ranked.
• Access Control Lists (ACLs) — Global Text Search respects table and field-level security, meaning users only see search results for records they have permission to access. This creates a security-filtered search experience where the same query returns different results for different users based on their roles and assigned ACLs. The search index contains all records but the display layer applies security filtering in real-time.
• User Preferences — the glide.ui.search_results_per_category system property and individual user preferences control how many results appear per Search Group. Users can also set personal search preferences that affect which tables they want to search by default, customizing their search experience beyond the admin-configured Search Groups.
• Knowledge Management — Knowledge articles have special search behavior within Global Text Search, including content-based relevance scoring and the ability to search within article attachments. The kb_knowledge table requires additional indexing configuration for full-text search of article content, not just metadata fields like other tables.
• Scheduled Jobs — the Text Search Index job runs automatically to rebuild search indexes when table schema changes or large data imports occur. Manual execution of this job is often required after adding new searchable tables or modifying Text Search Configuration records. Poor timing of these jobs can impact search performance during business hours, making job scheduling a critical operational consideration.
• Performance Analytics — Global Text Search generates significant database load during index rebuilds and can be monitored through the Performance Analytics application. Search query patterns and response times are tracked as platform metrics, helping admins identify when search configuration changes negatively impact system performance or when additional hardware resources are needed to support search load.

Junior vs Senior Knowledge Gap

Junior administrators typically focus on the visible configuration—creating Search Groups and adding Search Sources—without understanding the performance implications of their choices. They often add every potentially useful table to search groups, not realizing that each additional table increases query time and memory usage. The common mistake is treating Global Text Search like a database query tool, expecting it to return comprehensive results for complex searches when it's actually optimized for quick, relevant matches. Juniors also struggle with search troubleshooting because they don't understand the relationship between the ts_index_entry table, the indexing jobs, and the actual search experience users see.

The mental shift happens when someone has to support search in a large production environment and realizes that search performance directly impacts overall system performance. Senior professionals understand that Global Text Search is fundamentally about user workflow optimization—helping users find the right record to work on quickly—rather than comprehensive data discovery. They know that search configuration requires balancing competing demands: users want to find everything, but system performance degrades when search scope is too broad. This leads to strategic decisions about which tables truly need to be globally searchable versus those that should only be searched within specific applications or contexts.

Experienced architects know several things that never appear in documentation: Global Text Search can become a significant performance bottleneck in instances with large datasets, especially when users search for common terms that match thousands of records. The Lucene indexing happens asynchronously, so recently created or updated records might not appear in search results immediately, causing user confusion. Field-level security doesn't just filter results—it can make search appear "broken" to users who expect to find records they know exist but can't access. Search relevance scoring often produces unexpected results because it weights certain field types differently, and there's no simple way to explain to users why one incident appears before another in results.

The questions a senior architect asks reveal this depth of understanding: How will adding this table to global search affect peak-hour performance? Which fields in this table contain sensitive data that shouldn't be searchable even if the user can access the record? How often do index rebuilds need to run to keep search results current, and can the system handle that load? What's the user workflow that requires this data to be globally searchable, and could that workflow be better served by contextual search within the specific application? These questions come from having seen search implementations that looked successful in development but caused problems in production environments with real data volumes and usage patterns.

Quick Reference

• Search Groups can be restricted by role, allowing different user types to see different search categories—the ts_search_group table's roles field controls this visibility.
• The glide.ui.search.global_search_independent_multitab system property controls whether search results open in new tabs—disabling this forces all search results to open in the same tab, which many users prefer.
• Index rebuilds only process active records by default—the active=true filter is automatically applied to most table indexing, so inactive users, closed incidents, and archived records don't appear in search results.
• Search Sources have an order field that determines both the sequence of results within a Search Group and the priority during indexing—lower numbers get indexed first and appear higher in results.
• The Text Search Index scheduled job (TextSearchIndexJob) can be configured to run incrementally rather than full rebuilds, but incremental indexing sometimes misses updates and requires periodic full rebuilds to maintain accuracy.
• Wildcard searches using asterisks work inconsistently—they're supported for suffix matching (INC*) but not prefix matching (*001) due to Lucene limitations.
• Extended tables inherit the search configuration of their parent table automatically, but you can override this by creating specific Text Search Configuration records for the extended table with different field weightings.
• The ts_index_entry.document field contains the actual searchable content as a single concatenated string—this is what Lucene searches against, not the original table fields.
• Search results are limited to 1000 matches per table by the glide.ui.search.max_search_results system property—searches that would return more records show this limit rather than all matches, which can make comprehensive searches appear incomplete.
• Choice field labels are indexed for search, but reference field display values are not—searching for a user's name won't find incidents assigned to that user unless the assignment field is specifically configured for display value indexing in the Text Search Configuration.