Search
Search in Salesforce is the platform feature that lets users find records, files, articles, and conversations across the org by typing keywords into the global search bar (at the top of every page) or into object-specific search boxes.
Definition
Search in Salesforce is the platform feature that lets users find records, files, articles, and conversations across the org by typing keywords into the global search bar (at the top of every page) or into object-specific search boxes. The platform runs a SOSL-based full-text search engine against a dedicated text index, applies stemming and synonym matching, respects record-level sharing, and returns results ranked by relevance and recency.
The Search experience surfaces in several places: the global search bar in the Lightning header, lookup field searches when populating a record reference, Einstein Search (the AI-enhanced version that adds natural-language understanding), and developer-facing SOSL queries that programmatic features use to power custom search UIs. Behind every search box, the same underlying engine handles the work; configuration differences (which objects are searchable, which fields are indexed, what synonyms apply) shape what each user sees. Mature Salesforce orgs treat Search configuration as a first-class admin concern because search quality directly drives user productivity and adoption.
How Salesforce Search works and how to tune it for real users
How Salesforce Search works under the hood
Salesforce Search runs through a multi-stage linguistic pipeline. When a user types a query, the platform tokenizes the input (splits into words), lowercases everything, removes common stop words (a, the, is), applies stemming to reduce words to root form, expands the tokens with synonyms configured on the org, and searches against the platform text index. The index stores tokenized and stemmed versions of every searchable field. Results come back ranked by a relevance score that combines text match strength, record recency, and user-record access (records you own or recently viewed rank higher). The platform respects field-level security, sharing rules, and object-level permissions in the result set; users only see records they have read access to.
Global Search, lookup search, and Einstein Search
Three distinct search experiences sit on the same engine. Global Search is the top-of-page search bar in Lightning Experience; it queries across multiple objects at once and returns a unified result list. Lookup Search appears inside lookup fields when a user starts typing to find a related record; it queries one specific object and returns matching records. Einstein Search is the AI-enhanced version of Global Search that adds natural-language understanding (a search for closed-won deals last quarter parses into a structured query) and personalized result ranking based on the user past behavior. Each experience is configurable to varying degrees; the global search results page lets admins reorder objects, tune search relevance, and add filters.
Searchable objects and indexed fields
Not every object and field is searchable by default. Salesforce indexes a curated set of standard object fields (Account.Name, Contact.Name and Email, Opportunity.Name, Case.Subject, Knowledge Article body, and so on) plus all custom object fields marked External ID or Unique. Admins can extend the index through Search Layouts (which determine which fields appear in search results) and through field-level configuration. Some field types are not indexed at scale (Rich Text fields, formula fields with text output, fields with very high cardinality); the documentation lists which types are indexable and which are not. The indexing is asynchronous; newly created records and updated values become searchable within seconds to minutes depending on org volume.
Search synonyms, search aliases, and custom relevance
Several configuration knobs let admins tune search relevance for their org vocabulary. Synonym Groups (Setup, Synonym Groups) link terms that should match each other (car and automobile, laptop and notebook); a search for one term retrieves records containing the other. Search Aliases are record-level fields that hold business-specific terminology (informal product codes, internal nicknames) so search matches them as if they were canonical. Custom Search Layout configuration determines which fields appear in result rows and which fields are highlighted on hover. Einstein Search adds natural-language ranking on top of all of this. Mature search implementations use all of these together; relying on the default platform configuration almost always leaves real user productivity on the table.
Performance, scale, and the data volume problem
Search performance is generally fast on Salesforce because the platform text index is purpose-built. Most search queries return in well under a second even on orgs with millions of records. Performance issues surface in three patterns: very-high-cardinality fields (an Email field with 50 million unique values) that strain the index, very-broad queries with leading wildcards that bypass the index optimization, and security-heavy orgs where the sharing rule evaluation per record dominates the query time. For each, the platform provides mitigations: Custom Indexes added through Salesforce Customer Support, query refactoring to avoid leading wildcards, and Defer Sharing Calculations during sharing-heavy operations. Monitor search performance through the Setup Optimizer reports; chronic slowness is worth investigating before users complain.
Search permissions, security, and the search audit trail
Search respects every Salesforce permission layer. Object-level permissions (Read on Account) gate whether the object appears in search results. Field-level security gates whether specific fields appear in result columns and contribute to result ranking. Sharing rules and the role hierarchy gate which records the user can see. The platform never returns a record the user does not have read access to; the search result count and the displayed records reflect the user permissions, not the org full data. For audit purposes, Setup Audit Trail logs admin configuration changes to search (adding synonyms, changing search layouts, modifying searchable objects). Search itself is not logged at the per-query level for most orgs; Shield Event Monitoring adds this for orgs that need it.
Tuning Salesforce Search for real user productivity
Tuning Salesforce Search for your org is a four-piece configuration. The four steps cover: configure which objects and fields appear in global search results, set up synonym groups for org-specific terminology, customize search layouts to show the right fields in results, and enable Einstein Search if licensed. Each step compounds: a Search experience that prioritizes the right objects, knows the right synonyms, shows the right fields, and ranks by natural-language relevance is dramatically more useful than the default platform configuration.
- Configure which objects appear in global search results
From Setup, search Global Search Results, and configure the object ordering and the per-object result limits. Move the most important objects (Account, Contact, Opportunity, Case for sales-and-service orgs; custom objects for industry-specific orgs) to the top of the list. Set higher result limits for objects users search most frequently. Confirm that the right user audience sees the right objects through profile-level configuration. Test as a target user before activating broadly; layout that works for admins may not work for end users. Document the configuration in the search runbook.
- Set up Synonym Groups for org-specific terminology
From Setup, Synonym Groups, create a group for each pair of terms that should match each other in search. Common groups: car and automobile and vehicle, laptop and notebook and PC, and any business-specific equivalents your org uses. Add the equivalent terms inside the group; the platform treats them as interchangeable in search. For scope-limited synonyms (a sales team synonyms differ from a service team), use permission sets to scope the synonyms to specific user populations. Document the synonym groups in the search runbook so future admins understand the rationale for each.
- Customize Search Layouts to show the right fields
Per object, configure the Search Results layout (which fields appear in each row of search results) and the Lookup layout (which fields appear in lookup field searches). The default layouts show Name and a few standard fields; customize them to surface the fields users actually need to disambiguate (Account: Name, Industry, Owner, City; Contact: Name, Title, Email, Phone). Configure separate layouts per record type if the org uses record types to model different business processes. Test the layouts as a target user; layouts that work for admins may not work for end users searching from the field.
- Enable Einstein Search if licensed
From Setup, search Einstein Search, and activate the feature if the org has the appropriate license. Einstein Search adds natural-language understanding (a query like Acme opps closed last quarter parses into a structured query against Opportunity), personalized result ranking based on user behavior, and several quality-of-life improvements (suggested filters, related queries). The feature is included in some editions and an add-on for others; verify the license entitlement before promising the feature to users. Train users on the natural-language capabilities; without training, they default to keyword search and miss the Einstein advantage.
- Not every field is indexed by default. Rich Text, formula fields with text output, and very-high-cardinality fields may not appear in search results. Check the documentation for indexable field types.
- Search respects every permission layer. A user with limited access sees limited results; do not conclude the search is broken until you have tested with the actual user identity.
- Synonym Groups are global to the org by default. Permission sets can scope them, but inconsistent scope produces confusing search behavior across user populations.
- Leading wildcards in SOSL (FIND {*acm}) are blocked. The platform protects itself from full index scans; users searching with leading wildcards see the search rejected.
- Einstein Search requires training data and ongoing tuning. Enabling the feature without training users on its natural-language capabilities leaves most of the value untapped.
Trust & references
Straight from the source - Salesforce's reference material on Search.
- How Salesforce Search WorksSalesforce Help
- Global Search ResultsSalesforce Help
- Einstein Search OverviewSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is Salesforce Search?
Q2. What affects search quality?
Q3. When are records searchable?
Discussion
Loading discussion…