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.