Tìm kiếm không phải là truy vấn

🌐 Cũng có bằng 19 ngôn ngữ khác

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · ไทย · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)

Hình ảnh được tạo bằng AI

Được dịch bằng AI. Cộng đồng chưa xem xét. Đọc bằng tiếng Anh Phần này đã thay đổi trong bản tiếng Anh và chưa được dịch lại. (102)

Module 5 of 5 in the chapter Query and Retrieval Architecture, chapter 8 of the Data Architect course. Each module stands on its own. ⟲ Previous: How Salesforce Executes a Query · Next: the next chapter, Integration and Data Movement ⟲

Câu hỏi mô-đun này trả lời: Khi nào nên tìm kiếm thay vì truy vấn?

Ba mô-đun về truy vấn, chỉ mục, tính chọn lọc, kế hoạch truy vấn và skinny table đều giả định một điều: bạn biết mình đang tìm gì. Các chuyến giao hàng hôm nay của Redrock. Các trường hợp được sửa từ hôm qua. Chuyến giao hàng có mã tham chiếu đối tác DLV-8472914. Những câu hỏi có cấu trúc. Nhưng người ta không phải lúc nào cũng hỏi câu hỏi có cấu trúc. Đôi khi họ nói: “Tôi nhớ khách hàng có nhắc đến một chiếc tủ lạnh bị hỏng ở Tempe. Anh tìm được không?” Đó không thực sự là bài toán truy vấn. Đó là tìm kiếm. Và tìm kiếm không phải là truy vấn.

Truy vấn bắt đầu từ cấu trúc; tìm kiếm bắt đầu từ một cụm từ

SOQL tuyệt vời khi chúng ta biết cấu trúc: đối tượng, trường, điều kiện. Các lệnh công việc có Đối tác bán lẻ là Redrock và ngày dự kiến là hôm nay. Chúng ta biết thông tin nằm ở đâu, được biểu diễn thế nào và chúng ta đang kiểm tra điều gì, và cơ sở dữ liệu có thể dùng mọi thứ chúng ta đã thiết kế trong chương này.

Giờ thì: “tìm bản ghi có cụm từ tủ lạnh bị hỏng.” Đối tượng nào? Một trường hợp, một lệnh công việc, một ghi chú? Tiêu đề, mô tả, một trường văn bản khác? Người dùng không biết, và không nên phải biết. Đó là lúc SOSL, Salesforce Object Search Language, xuất hiện. Thay vì “tôi nên lọc trường nào?”, nó bắt đầu bằng “tìm đoạn văn bản này.” Một bài toán truy xuất khác về bản chất.

Tôi đã thấy lập trình viên ép tìm kiếm vào SOQL. “Cho người dùng gõ chút văn bản rồi tìm khách hàng”, và truy vấn cứ phình ra: Name LIKE … OR Email LIKE … OR Phone LIKE … OR Description LIKE … OR một trường khác, rồi một trường nữa. Đến một lúc, hãy dừng lại và hỏi: chúng ta đang truy vấn, hay đang tìm kiếm? Nếu yêu cầu là khám phá văn bản trên nhiều trường, SOSL có thể là công cụ gọn hơn. Nó sinh ra để làm việc đó. Đừng ép một bài toán tìm kiếm vào hình dạng truy vấn chỉ vì SOQL là công cụ bạn dùng nhiều nhất.

Remember the hardest case from module 3: contains. Description LIKE '%refrigerator%' has no way into the drawer, so the librarian walks every shelf. Search was built for exactly that question. Salesforce says it directly: “When a given search can use either language, SOSL is generally faster than SOQL if the search expression uses a CONTAINS term,” because “SOSL can tokenize multiple terms within a field (for example, multiple words separated by spaces) and builds a search index off this.” Looking for “John” in “Paul and John Company” is a search question (Using SOQL and SOSL (mở trong thẻ mới), Best Practices for Deployments with Large Data Volumes, Winter ‘27). ⟲

Nhấp để phóng to

“Contains” forced into a query: no way into an index. Slow. ⟲

Nhấp để phóng to

The same words, asked as a search: straight to the matches. Query knows the structure. Search knows the term. ⟲

How Search Works: Tokens First, Then the Fetch

Back to the library. A database index is the catalog for “books by this author” or “books with this identifier.” Now I want every book containing the phrase “broken refrigerator.” Reading every page of every book for each search would be ridiculous, so search builds its own index over the words. “The Salesforce search architecture is based on its own data store, which is optimized for searching for that text” (Search Architecture (mở trong thẻ mới), Winter ‘27): a different engine for a different kind of question. ⟲

How does it fill that store? “When you create a record, the search engine breaks up the searchable content into smaller pieces, called tokens. It stores the tokens in a search index. The search index is much like a book index—each token in the index has a link back to the record it came from” (How Einstein Search Works (mở trong thẻ mới), Salesforce Help). When you search, your words are broken into tokens the same way and matched against that index. ⟲

And then comes a step people miss. “Salesforce performs indexed searches by first searching the indexes for appropriate records, then narrowing down the results based on access permissions, search limits, and other filters … The result set is then used to query the records from the database to retrieve the fields that a user sees” (Search Architecture (mở trong thẻ mới)). In module 4’s four words: search finds which records in its own index, and then a regular fetch from the database brings back their fields. Two engines, one after the other. ⟲

And it’s not only the search box. Salesforce lists search behind “Advanced and global searches”, “Find boxes and lookup fields”, “Suggested Solutions and Knowledge Base”, “Web-to-Lead and Web-to-Case”, “Duplicate lead processing”, and SOSL from Apex and the API (same source). Like the librarian, search is working in places nobody thinks of as “search.” ⟲

Độ mới là một phần của thiết kế

That index is asynchronous. New and changed records are queued and indexed by separate servers, and “it could take about 15 minutes or more for the updated text to become searchable” (Search Architecture (mở trong thẻ mới)). Big loads take longer: “If a record is created or updated using bulk API, it may take more than 15 minutes for the record to be searchable … wait for a few hours for it to be indexed” (How Einstein Search Works (mở trong thẻ mới)). So after a migration, the search index is behind for a while, just as module 4’s notebook of statistics is behind until the nightly run. ⟲

So search and query have different freshness. Steve Trucking creates a case at 10:00; at 10:01 a SOQL query returns it, while a text search for words in its description depends on whether the search index has caught up. That isn’t a defect. It’s a property of the mechanism. “The moment a delivery exception is created, our automation must find it.” Would I build that on text search? No. The process knows the work order, the exception type, the date and the status, so a structured query is the deterministic choice. “A care agent wants old cases where customers mentioned damaged refrigerators”? Search makes far more sense. Different requirement, different engine, different freshness. Choose the retrieval mechanism from the question, not from habit. ⟲

Tìm kiếm vượt qua các đối tượng, và có thể tìm ra quá nhiều

Một trong những điểm mạnh của SOSL là người dùng không cần biết đối tượng nào chứa câu trả lời. Một điều phối viên tìm “Henderson”, và đó có thể là một tài khoản, một liên hệ, một lệnh công việc hay một trường hợp. Người dùng đang tìm thứ đó, chứ không nghĩ “đầu tiên truy vấn Contact.LastName, rồi Account.Name, rồi Người nhận của lệnh công việc, rồi mô tả trường hợp”. Tìm kiếm khớp với cách người ta thực sự tìm thông tin.

That creates another problem. Make everything searchable (every object, field, historical record, every bit of text) and then search “Smith,” and the user is overwhelmed. Search didn’t fail; it found too much. That’s search crowding, and at scale it matters as much as speed. ⟲

Search Crowding, Step by Step

Salesforce defines it plainly: “Search crowding–having too many unhelpful search results–can overwhelm you with irrelevant records and slow down search. To avoid search crowding, the search engine limits the number of records it analyzes” (How Search Crowding Affects Search Results (mở trong thẻ mới), Salesforce Help). The limit is there to protect search. The cost is that the record you wanted can fall outside it. ⟲

Let’s walk through one search. A Steve Trucking care agent is looking for a case about a damaged refrigerator for a customer named Henderson. She types Henderson into global search. Henderson is also a city, so the word appears on thousands of delivery addresses. Salesforce’s own example uses these numbers, so let’s use them too: ⟲

1. Every record that matches. The search index finds 3,200 records with the word Henderson: accounts, contacts, cases, and a great many work orders. ⟲
2. The limit. “Search limits the results to the first 2,000 records found, so 1,200 records aren’t included in your search results” (same source). If her case is among those 1,200, it’s gone before anything else happens. ⟲
3. Permissions. Only now does search check what she can see. “Search analyzes only 2,000 records, which can include records you don’t have access to. Of the 2,000 analyzed, you don’t have access to 100 of them so you don’t see them in your results. You only see 1,900 records returned” (same source). Those 100 still took up room in the 2,000. Read that again: the cutoff comes before sharing, so records she will never see can take places in the 2,000 and push the record she needs past the line. ⟲
4. Shared out across objects. When a search names several objects, the 2,000 are shared out. In Salesforce’s words: “If you query one object only, a maximum of 250 records are returned. To return up to 2,000 results, include either the WHERE clause or ORDER BY clause. If you query multiple objects, each object returns up to the minimum number between 2,000/n (where n=number of objects) and 250.” Search ten objects at once and each one gets at most 200. And the results aren’t the same for everyone: “Admins (users with the View All Data permission) see the full set of results returned”, while other users see only what they have access to, and “Results sets and order vary by the user issuing the search and can change throughout the day as records are added or removed from the index” (same source). The order varies too: Salesforce ranks results “based on search term frequency, order, uniqueness, record activity, and access permissions. Search result relevance can vary for each user” (How Einstein Search Works (mở trong thẻ mới)). So when someone says “I searched and it wasn’t there,” the first questions are: how many records matched before the limit, and who were you? ⟲
5. Ranked. What’s left is put in order of relevance, so even when her case survives, it may be far down the list under 1,900 other Hendersons. ⟲

Nhấp để phóng to

The cutoff comes first, sharing second. Records she can’t see take places in the 2,000, and her case lands in the discarded bucket. ⟲

Now push it to the worst case the mechanics allow. An object holds 100,000 records, and sharing lets this user see 1,000 of them. She’s looking for 10 specific records, and she can see all 10. Her search term matches 3,000 records. The first 2,000 found are all records she can’t see; her 10 are among the 1,000 past the cutoff, in the discarded bucket. Sharing removes all 2,000 that were kept, and she gets no results, for records she knows are there and is allowed to see. ⟲

Nhấp để phóng to

Visible to her, and still not found: the 2,000 places went to records she can’t see. ⟲

To be fair to Salesforce, this is the edge, not the everyday. The same Help article says: “The search engine’s priority is to return accessible records for users with limited access in an org” (How Search Crowding Affects Search Results (mở trong thẻ mới)), and relevance takes access into account. Most of the time that keeps users with narrow access out of this trap. But when someone with limited access swears a record is missing from search and then finds it by opening a list view, this is why, and the fix is the same: a more specific search, fewer objects, fewer records that compete. ⟲

That’s the heart of it. “The search engine looks for matches to the search term across a maximum of 2,000 records”, and only then applies each user’s permissions, so the user sees only what they’re allowed to (SOSL Limits on Search Results (mở trong thẻ mới), SOQL and SOSL Reference). So 2,000 irrelevant matches, including records this user can’t even see, can crowd out the one they wanted before sharing ever trims the list. The question isn’t only “how fast is search?” It’s did we design search so the useful answer can surface? ⟲

So when someone says “I searched and it wasn’t there,” the first questions are: how many records matched before the limit, how many objects were searched, and who was searching? ⟲

Mitigating Search Crowding: A Playbook

The fix is always the same idea: fewer, better matches before the limit. Here’s the playbook I’d hand an admin and an architect when someone says “I searched and it wasn’t there.” Work through it in order. ⟲

Nhấp để phóng to

Rule out freshness, access and searchability first. Then measure. ⟲

Step 1: Rule Out the Other Causes

Not every missing record is crowding. Check the simple causes first: ⟲

• Is it too new? Text can take a few minutes to be indexed, and “If a record is created or updated using bulk API, it may take more than 15 minutes for the record to be searchable … wait for a few hours” (How Einstein Search Works (mở trong thẻ mới)). A record loaded this morning may not be searchable yet. ⟲
• Can this user see it? Open it from a list view or report as that user. If they can’t, it’s access, not search. “Admins can also check profile and permission settings for access to objects” (How Search Crowding Affects Search Results (mở trong thẻ mới)). ⟲
• Is the object searchable at all? “By default, search is disabled for new custom objects. Admins enable Allow Search when setting up new custom objects” (though “A custom object that’s associated with a custom tab is searchable by default”) (Searchable Fields: Custom Object (mở trong thẻ mới)). And remember the 120-day rule: an unsearched custom object can lose searchability. ⟲
• Does an exact, unique term find it? Search for something only that record has, like its full name or reference number. If that works and the broad term doesn’t, you’re looking at crowding. ⟲

Step 2: Measure the Crowd

Search the broad term again, then search it in one object at a time. If a search comes back at the limit, 2,000 overall or 250 for a single object without a WHERE or ORDER BY, the results were cut off. Note which object supplies most of the matches. In the Henderson example, it’s the work orders, whose delivery addresses are full of the word. ⟲

Step 3: Cut the Noise at the Source

Data can deserve to exist without deserving to appear in search. These are Setup changes, made in Search Manager (“To use Search Manager: Customize Application AND View Setup”). Do them in this order, from the cheapest to the most structural: ⟲

1. Turn off objects these users don’t search, by profile. “You can manage searchable objects for each profile in global search.” From Setup, enter Search Manager, select Query Configurations, select the configuration, and “in the Objects List, select an object and turn searchability on or off” (Manage Searchable Objects and Fields (mở trong thẻ mới)). If care agents never look for work order line items, their profile shouldn’t search them. ⟲
2. Take noisy custom fields out of the index. From Setup, enter Search Manager, select Index Management, choose the object, and next to the field choose Remove from search index. “Removed fields don’t appear in search results and aren’t used to match results. You can’t remove standard fields,” and “Your changes can take a few hours” (Manage the Search Index (mở trong thẻ mới)). A long description or address field that matches everything is a good candidate. ⟲
3. For an object nobody should search, disable its search index. That stops “making its data searchable and stop[s] index credit consumption for that object” (Explore the Search Index with Search Manager (mở trong thẻ mới)). ⟲
4. Archive history that no longer needs to be found. Old completed work orders stay in the index and keep competing. Archiving (chapter 7 and module 4’s wrap-up) shrinks the crowd for search and for queries. ⟲
5. Put identifiers where search looks first. A lookup searches only the record name, and a NAME search group only name fields. If people find a delivery by its partner reference, make sure that value lives in a field search treats as a name or identifier. ⟲

Step 4: Fix the Searches You Build

For every custom search, in Apex, in a component or in an agent’s tool: ⟲

• Return only the objects the question needs, each with a WHERE: “For SOSL, selective filters reduce the number of irrelevant results” (SOQL and SOSL (mở trong thẻ mới), best practices, Winter ‘27). ⟲
• Use a search group: IN NAME FIELDS, EMAIL or PHONE, so an address field full of “Henderson” doesn’t match a name search. ⟲
• Prefer specific terms to wildcards, and single-object searches “for greater speed and accuracy” (Searching (mở trong thẻ mới), best practices, Winter ‘27). The next section, Asking Search Well, has the details. ⟲

Step 5: Teach the People Searching

Put three habits in the training and the help text: ⟲

• A more specific term: “Use a more specific search term, such as Industrial Computing San Francisco” (How Search Crowding Affects Search Results (mở trong thẻ mới)). For our agent, Henderson refrigerator, or the customer’s full name. ⟲
• One kind of record: “if you’re looking for an account record, search for Industrial Computing in Accounts” (same source). ⟲
• The complete name in a lookup: “A lookup search uses only the record name”, so “enter Jupiter Hotels instead of just Hotels” (same source). ⟲

Nhấp để phóng to

The same search, done well: a specific term in one object, and her case comes through. ⟲

Step 6: Verify as That User

Index changes “can take a few hours”, so check the next day, not the next minute. Repeat the original search as a user with that profile, not as an admin. An admin with View All Data sees results other users don’t, so an admin’s search proves nothing about crowding. ⟲

Step 7: Keep It Healthy

Searchability drifts as an org grows, so make it part of the regular review: ⟲

• When a new object or a big text field arrives, decide on purpose whether it’s searchable, and for which profiles. ⟲
• Watch the 120-day rule for custom objects people search only rarely. ⟲
• Keep sensitive fields out of the index. Search applies field-level security only to “up to 100 searchable custom fields per object” (Explore the Search Index with Search Manager (mở trong thẻ mới)), and Salesforce’s advice is direct: “If a field contains sensitive information and you couldn’t apply field-level security to it, remove the field from the index” (Manage the Search Index (mở trong thẻ mới)). ⟲

Nhấp để phóng to

Fewer, better matches before the limit. Three people can make that happen. ⟲

Asking Search Well

You don’t need to write SOSL to be an architect, but you should recognize the levers, because they’re how you keep the right answer from being crowded out: ⟲

• Search groups. Search only the kinds of fields that matter: “Search groups include NAME, EMAIL, and PHONE fields. For example, FIND ‘Avery Smith’ IN NAME FIELDS RETURNING Account(Id,Name), Lead(Id,Name)” (same source). ⟲
• RETURNING. Name the objects, and the fields to bring back, and add a WHERE or ORDER BY to get past the 250-record default for one object. ⟲
• Specific terms. “Keep searches specific and avoid using wildcards, if possible. For example, search with Michael instead of Mi*.” And “Use single-object searches for greater speed and accuracy” (Searching (mở trong thẻ mới), best practices, Winter ‘27). ⟲
• Wildcards and operators. An asterisk matches “zero or more characters at the middle or end of your search term”, and a question mark exactly one. Quotes keep a phrase in order, and AND, OR and AND NOT combine terms (FIND {SearchQuery} (mở trong thẻ mới), SOQL and SOSL Reference). Notice: the middle or the end. Like the index in module 3, search does best when it knows how a word starts. ⟲
• Divisions. SOSL can be limited to one division (WITH DivisionFilter), the partitioning tool from module 4. ⟲

And a few limits worth knowing. A transaction in Apex can run “Total number of SOSL queries issued: 20”, and “Total number of records retrieved by a single SOSL query: 2,000” (Execution Governors and Limits (mở trong thẻ mới), Apex Developer Guide, Winter ‘27). One quiet trap: “If SearchQuery is longer than 4,000 characters, any logical operators are removed. For example, the AND operator in a statement with a SearchQuery that’s 4,001 characters defaults to the OR operator, which could return more results than expected” (SOQL and SOSL Limits for Search Queries (mở trong thẻ mới)). ⟲

Test knowledge. Know SOSL’s limits: at most 2,000 records searched, then permissions applied; 250 for one object unless you add WHERE or ORDER BY; up to 2,000 divided by the number of objects (and no more than 250 each) when you search several; 20 SOSL queries per Apex transaction. Know the levers: search groups (NAME, EMAIL, PHONE), RETURNING, specific terms over wildcards, and wildcards only in the middle or at the end. ⟲

Search Runs as Someone

Search reaches across many objects and returns text, so who it runs as matters. In Apex, that changed recently. “Apex database operations, such as SOSL and SOQL queries, DML statements, and Database methods, now run in user mode by default. In user mode, database operations enforce the sharing rules, field-level security, and object permissions of the current user. In earlier API versions, database operations default to system mode” (Database Operations Run in User Mode by Default (mở trong thẻ mới), release notes, API version 67.0 and later). Code can still say which mode it wants: “To indicate an access mode for a SOQL or SOSL query, insert a WITH USER_MODE or WITH SYSTEM_MODE clause” (Set an Access Mode for Database Operations (mở trong thẻ mới), Apex Developer Guide). ⟲

And because a search screen takes whatever the user types, it’s a door for injection. Salesforce’s Well-Architected guidance names it: “SOQL or SOSL injections are scoped to a reading that discloses records or fields that the caller shouldn’t be able to reach by widening query conditions”, and asks you to “Validate and sanitize all user input that prevents injection across SOQL, SOSL, and HTML contexts” (Trust (mở trong thẻ mới)). ⟲

Search in Other Languages

If your org works in more than one language, search doesn’t behave the same in all of them. “Search is available for Fully Supported Languages. However, not all features, including lemmatization and synonym groups, are available in all languages and for all objects. Only exact matches are returned for searches in End-User Languages” (How Einstein Search Works (mở trong thẻ mới)). Lemmatization is what lets a search for “deliveries” find “delivery”; without it, only the exact word matches. And for languages written without spaces, the engine uses “morphological tokenization” to find the words, so a search for Kyoto (京都) doesn’t match Tokyo Prefecture (東京都) (FIND {SearchQuery} (mở trong thẻ mới)). For a global care team, test search in each language people actually use. ⟲

Tìm kiếm để khám phá, truy vấn để vận hành

Không phải chọn một trong hai. Nhân viên nhớ “tủ lạnh hỏng Henderson”; tìm kiếm tìm ra trường hợp hoặc lệnh công việc; khi đã có danh tính của nó, truy xuất có cấu trúc tiếp quản. Tìm kiếm để khám phá; truy vấn để vận hành.

Nhưng có bẫy ở cả hai phía. Khi tìm kiếm trở nên tốt, các đội lười đi với cấu trúc: “không cần mô hình hóa cái đó, người ta tìm kiếm là ra.” Không. Nếu thông tin điều khiển tự động hóa, tích hợp, bảo mật, báo cáo, quy tắc nghiệp vụ, việc khớp hay truy xuất tất định, hãy cho nó cấu trúc. Nếu Đối tác bán lẻ là một mối quan hệ có ý nghĩa, hãy mô hình hóa nó; đừng chôn tên nó trong một đoạn mô tả rồi hy vọng tìm kiếm sẽ thấy. Tìm kiếm tuyệt vời cho việc khám phá; nó không phải là mô hình dữ liệu. Và ngược lại: nếu người ta thực sự cần khám phá văn bản trên nhiều trường và đối tượng, đừng bắt họ đi qua một mê cung bộ lọc có cấu trúc chỉ vì như vậy dễ hơn cho đội phát triển.

Salesforce’s own case study shows the pattern for a custom search screen. A customer let users search on any of 20 fields, with wildcards, across several objects, and performance suffered. The fixes: “Use only essential search fields”, “De-normalize the data from the multiple objects into a single custom object”, and “Dynamically determine the use of SOQL or SOSL to perform the search based on both the number of fields searched and the types of values entered. For example, very specific values (i.e., no wild cards) used SOQL to query, which allowed indexes to enhance performance” (Custom Search Functionality (mở trong thẻ mới)). Exact values go to the librarian; words go to search. ⟲

Tìm kiếm lại trở nên thú vị

Nhiều năm nay tôi không thấy SOSL được dùng nhiều như SOQL trong các dự án Salesforce; phát triển giao dịch bắt đầu từ bản ghi có cấu trúc và truy vấn có cấu trúc. AI đang làm cho kiến trúc tìm kiếm thú vị trở lại. Một tác tử không phải lúc nào cũng bắt đầu bằng WHERE Retail_Partner__c = 'Redrock'. Ai đó hỏi: “những khách hàng nào đã phàn nàn về thiết bị gia dụng bị hỏng?” hay “có gì về sự cố giao hàng ở địa điểm Henderson không?” Giờ chúng ta đang chuyển từ truy xuất có cấu trúc chính xác sang tìm theo từ ngữ, và cuối cùng là theo ý nghĩa.

And keyword search still isn’t semantic search. SOSL finds words. “Find customers unhappy because deliveries keep arriving late” may match records that say “missed window,” “driver arrived after closing,” “third reschedule” or “came two days later,” none of them using the words in the question. Now we’re asking about meaning, which brings in semantic retrieval, and, combined with structure, hybrid retrieval. The grounding chapter takes that up in Choosing How the Agent Gets the Data (coming soon). ⟲

Agents search too. Salesforce’s hosted MCP server gives AI agents a find tool alongside soqlQuery: it “Executes a text search across multiple Salesforce objects simultaneously … Returns a maximum of 2,000 records total. Use search groups to narrow scope” (SObject All (mở trong thẻ mới), Hosted MCP Servers, checked 2026-10-22). The same limits, the same crowding, the same need for specific terms, now asked by a machine that doesn’t get tired of asking. ⟲

Steve Trucking: Công cụ nào?

• “Cho tôi các chuyến giao hàng hôm nay của Redrock.” Đối tượng, đối tác, ngày: có cấu trúc. SOQL.
• “Tìm bản ghi mà ai đó nhắc đến bến bốc dỡ bị hư hại.” Biết từ ngữ, không biết trường hay đối tượng: khám phá văn bản. SOSL.
• “Tìm những khách hàng có vẻ bực bội vì chậm trễ lặp đi lặp lại.” Ý nghĩa tương tự, từ ngữ khác: truy xuất ngữ nghĩa.
• “Tìm những khách hàng Redrock đang bực bội có chuyến giao hàng đang hoạt động trong tuần này.” Ý nghĩa cộng bộ lọc có cấu trúc: truy xuất kết hợp.

Kiến trúc sư quyết định gì ở đây

• Whether a requirement is structured retrieval, text discovery or something else, instead of defaulting to SOQL; and whether a “contains” belongs in search. ⟲
• Những đối tượng và nội dung nào đáng được tìm kiếm, để nhiễu khối lượng lớn không chen lấn mất kết quả hữu ích.
• Whether search-index freshness is acceptable, including after bulk loads, or the process needs deterministic structured retrieval. ⟲
• How the 2,000-record limit, its split across objects, and permissions affect search quality at production volume. ⟲
• Who search runs as, in code and for agents, and how user input is protected from injection. ⟲
• How search behaves in each language the business uses. ⟲
• Ở đâu tìm kiếm nên khám phá bản ghi và truy vấn có cấu trúc nên tiếp quản.

Nếu họ hỏi các lệnh công việc có đối tác là Redrock và ngày là hôm nay, đó là một câu hỏi có cấu trúc: truy vấn. Nếu họ hỏi bản ghi mà ai đó viết về một chiếc tủ lạnh hỏng, họ đang tìm kiếm: tìm kiếm. Đừng xây mười cái OR chỉ vì SOQL quen thuộc, và đừng tìm kiếm cả vũ trụ chỉ vì bật tìm kiếm ở mọi nơi thì dễ. Tìm kiếm không phải là truy vấn. Và câu hỏi tiếp theo trở nên dễ hơn: tôi biết cấu trúc, từ ngữ, hay ý nghĩa?

Tìm hiểu thêm

• Salesforce Developers, Best Practices for Deployments with Large Data Volumes (Winter ‘27), checked 2026-11-01: Search Architecture (mở trong thẻ mới), Using SOQL and SOSL (mở trong thẻ mới), best practices for Searching (mở trong thẻ mới) and SOQL and SOSL (mở trong thẻ mới), and the Custom Search Functionality (mở trong thẻ mới) case study. ⟲
• Salesforce Developers, SOQL and SOSL Reference, SOSL Limits on Search Results (mở trong thẻ mới) and FIND {SearchQuery} (mở trong thẻ mới), checked 2026-11-01. ⟲
• Salesforce Help, How Einstein Search Works (mở trong thẻ mới), checked 2026-11-01: tokens, indexing time, the 120-day rule, ranking, languages. ⟲
• Salesforce Developers, SOQL and SOSL Limits for Search Queries (mở trong thẻ mới) (Limits Quick Reference) and Apex Developer Guide, Execution Governors and Limits (mở trong thẻ mới) and Set an Access Mode for Database Operations (mở trong thẻ mới), Winter ‘27, checked 2026-11-01. ⟲
• Salesforce Help, release notes, Database Operations Run in User Mode by Default, Not System Mode (mở trong thẻ mới), API version 67.0, checked 2026-11-01. ⟲
• Salesforce Architects, Well-Architected, Trust (mở trong thẻ mới), checked 2026-11-01: SOQL and SOSL injection. ⟲
• Salesforce Developers, Hosted MCP Servers, SObject All (mở trong thẻ mới), checked 2026-11-01: the find tool. ⟲
• Salesforce Help, How Search Crowding Affects Search Results (mở trong thẻ mới), checked 2026-11-01: the definition, the numbers and the suggestions. ⟲
• Salesforce Help, Search Manager: Manage Searchable Objects and Fields (mở trong thẻ mới), Manage the Search Index (mở trong thẻ mới), Explore the Search Index with Search Manager (mở trong thẻ mới), and Searchable Fields: Custom Object (mở trong thẻ mới), checked 2026-11-01. ⟲