Using wildcards safely in SOSL and SOQL

Working with wildcards in Salesforce is a developer activity rather than an admin configuration. The four-piece routine covers: pick the right query language (SOSL or SOQL), apply the right wildcard syntax for that language, escape user input to prevent injection, and test under realistic data volumes. Each step matters; skipping any of them produces either bad results or production performance problems that only surface at scale. This guide covers the standard pattern for building a custom search feature; the same principles apply to admin tasks like Report criteria with LIKE filters.

1. 1
   Pick SOSL or SOQL based on the query shape

   Decide whether the query is text-search across multiple objects (SOSL) or precise filtering on a known object (SOQL). For global search bars and auto-complete features, SOSL is almost always the right choice; it queries the text index, returns results across multiple objects, and handles fuzzy text matching well. For lookup operations with a known object and exact field criteria, SOQL with LIKE is appropriate. Mixing the two (SOSL for the broad search, SOQL for the detail filter) is also fine and often necessary. Document the query-type decision in the code so future developers maintaining the search understand which constraints apply.

2. 2
   Apply the right wildcard syntax for the chosen language

   For SOSL, append asterisk (*) for zero-or-more-character match, or use question mark (?) for single-character match. Place wildcards at the end of the search term (FIND {acm*}) or both ends (FIND {*acm*}) but never at the start alone (FIND {*acme} is invalid). For SOQL LIKE, use percent (%) for multi-character match and underscore (_) for single-character match. WHERE Name LIKE acm% for prefix match, WHERE Name LIKE %acm% for substring match. Test each query in Developer Console or Workbench before embedding in code to confirm the syntax is right.

3. 3
   Escape user input to prevent injection

   Before assembling a dynamic SOSL or SOQL query from user input, escape special characters using Salesforce String.escapeSingleQuotes() or equivalent. Without escaping, a user typing a single quote, backslash, or wildcard character can break the query syntax or, worse, inject malicious filtering. Treat all user input as untrusted; never concatenate user input directly into a query string. For LWC components, the wrap-and-escape happens in the Apex method that receives the input; for Apex Triggers and Classes, do the escaping at the input boundary. Document the escaping pattern as part of the developer guidelines.

4. 4
   Test under realistic data volumes

   In a sandbox refreshed from production (or a Partial Copy with representative data), test the search feature at realistic record counts. Confirm query performance under load: response time stays under a second for the common case, well below governor limits. Check edge cases: empty input, very short input (one or two characters), input with special characters, very long input. For SOSL wildcard searches, confirm the platform accepts the query (a search with too few non-wildcard characters is rejected). Document the performance characteristics in the technical design so future maintainers know what the search is expected to handle.