Advanced Search
Advanced Search in Salesforce is the search experience that exposes object-specific filters, multi-criteria text matching, and configurable field scope beyond the simple top-bar global search.
Definition
Advanced Search in Salesforce is the search experience that exposes object-specific filters, multi-criteria text matching, and configurable field scope beyond the simple top-bar global search. In Lightning Experience, it shows up as the All Objects search results page where users can scope to one object, apply field-level filters, narrow by owner or date, and re-sort results. In Salesforce Classic, Advanced Search was a separate dialog with explicit filter rows. Both UIs run against the Salesforce search index, the same index used by global search, with the same tokenisation rules and the same field-level visibility checks.
Advanced Search matters because the global search shortcut gets users to the right ten records, while Advanced Search gets them to the right one. The simple text box in the header runs a fuzzy match across searchable fields on every searchable object. That works fine for I know the Account name but breaks down on I need the Account in California with a renewal in March owned by Maria. Advanced Search exposes the additional filters that let users narrow exactly that case without leaving the search experience to build a list view.
How Salesforce search actually works under the hood
The search index and what counts as searchable
Every searchable Salesforce record gets indexed on insert and update. The platform maintains a separate search index from the relational data, so searching does not run a SOQL query, it runs a SOSL query against that index. Not every field is indexed. Standard text, email, phone, picklist, and auto-number fields are indexed by default. Long text areas and rich text areas are partial-indexed by token. Formula fields are usually not indexed. Custom fields can be marked External ID or Unique to bias the indexer.
Field-level filters in the search results
The Lightning All Objects results page lets the user pick an object and then filter by any field that has been added to the Search Layout. Filters honour record-level sharing, so a user who cannot see a record never sees it in results even if it matches the text query. Salesforce evaluates the text query first against the search index and then the structured filters on top of the resulting record IDs.
Quoted phrases, operators, and wildcards
Search supports a small but useful set of operators: quoted phrases for exact-sequence matching, the asterisk for wildcard matching at the end of a token, the question mark for single-character wildcard, AND, OR, and NOT for boolean combinations. Leading wildcards are not allowed because the index is left-anchored on each token. Users who type acme are searching for tokens starting with acme, not containing acme.
SOSL behind the scenes
Every Advanced Search query is translated into a SOSL FIND statement that runs against the index. Developers can run the same SOSL directly through Apex or the REST search API to expose Advanced Search-style behaviour in custom UIs. The benefit is consistency: the same tokenisation, the same field weighting, the same sharing enforcement that the standard UI uses applies to custom code.
Per-object configuration of searchable fields
Each object has a Search Layout that controls which fields appear in the search results table, which fields show up as filterable, and which appear in lookup search results. Admins tune this per object to make search useful. The default search layout is rarely the right one beyond the smallest orgs; adding a few high-signal fields (Region, Owner, Status) makes Advanced Search dramatically more useful.
Lookup search reuses the same index
When a user types into an Account lookup on an Opportunity, the typeahead results come from the same search index Advanced Search uses. Tuning the Search Layout for one improves the other. Admins who add Industry and Region to the Account search layout make both Advanced Search and Opportunity lookups easier to disambiguate. The reverse is also true: removing a field from the layout hides it from typeahead.
Search filters via Setup
Beyond per-object layouts, admins can configure org-wide search settings: which objects are searchable at all, how many results per object the dropdown previews, and whether enhanced lookup is on. Search Settings is a single Setup page that is often overlooked. A 30-second visit there can dramatically improve search quality across the org.
Limits and common surprises
The search index is eventually consistent. Records created seconds ago may not appear in search results until the indexer catches up; in normal operations the delay is sub-second to a few seconds. Bulk loads can push the lag higher. Searches that return too many candidates get truncated at platform limits (200 results per object). Long-tail edge cases, like a record whose name field is empty, can simply not appear no matter how clever the search syntax is.
How to make Advanced Search useful in your org
The defaults are mediocre. A short pass on search settings and per-object search layouts is the highest-leverage 30 minutes an admin can spend on user experience.
- Open Search Settings
Setup, search for Search Settings. Confirm Enhanced Lookups is on, set the number of search results per page, and choose how many objects appear in Search Results.
- Tune each object's Search Results layout
Setup, Object Manager, open each high-traffic object, then Search Layouts, then Search Results. Add the high-signal disambiguation fields (Region, Owner, Status, Stage) and remove ones nobody uses.
- Tune Lookup search layouts in parallel
Still in Search Layouts, edit Lookup Dialogs. The same fields that disambiguate full search usually disambiguate lookup typeaheads.
- Train users on operators and wildcards
Most users do not know about quoted phrases, AND/OR/NOT, and the asterisk wildcard. A short cheat sheet plus a quick demo unlocks much better search behaviour without any configuration.
- Audit results quarterly
Run sample searches every quarter against real records and watch what reps actually type. Adjust layouts as record models and team structures change.
- Leading wildcards are not supported. Searching acme finds Acme Corp but not New Acme Inc; the user has to type the leading token.
- The search index is eventually consistent. Records created seconds ago may not appear in search until the indexer catches up.
- Long text areas and rich text areas are only partially indexed by token. Searching for a substring inside a body field is not reliable.
- Search Layouts and List View filters are different surfaces. Admins sometimes add fields to one and assume the other follows. They do not.
Trust & references
Cross-checked against the following references.
- Search in SalesforceSalesforce Help
- SOSL ReferenceSalesforce Developer Docs
Straight from the source - Salesforce's reference material on Advanced Search.
- Configure Search SettingsSalesforce 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. Who can benefit from understanding Advanced Search?
Q2. How does Salesforce's multi-tenant model affect Advanced Search?
Q3. What architecture concept is Advanced Search an example of?
Discussion
Loading discussion…