The question behind the empty result
An agent remembers a conversation with someone called Maria about a delayed order. They type Maria into the dashboard search box. Nothing comes back. They try the order number, then the phrase they remember her using. Still nothing.
The natural conclusion is that search is broken, or that the data has been purged. Neither is true. The search box is doing exactly what it was built to do, which is to search two specific things, and a chat transcript is not one of them.
Knowing the boundary turns a frustrating tool into a predictable one, and more importantly it tells you where to go instead.
Two record types, and only two
The dashboard search runs two independent queries: one over tickets, one over knowledge base articles. It presents them as two result groups on one page.
That is the entire scope. It does not search chat transcripts. It does not search contacts or visitor records. It does not search offline messages, missed chats, macros, canned responses, agents or settings. If the thing you are looking for is not a ticket or a help article, this box will never find it, no matter how the query is phrased.
Each side degrades independently and visibly. If the ticket store is not present on a site, the ticket half reports itself unavailable while the article half still works, and the reverse holds too. So an empty ticket section does not necessarily mean no matches; read the surrounding message rather than the empty space.
The two-character minimum
A query shorter than two characters does not run at all. Neither query is executed and the page renders with nothing on it.
This is a sensible guard against a single-character substring match dragging back most of the database, but it is silent. Searching for a one-character code, or hitting enter on a stray keystroke, produces a page that looks exactly like a search that ran and found nothing. If you get a blank result for a very short query, add a character before concluding anything.
Which ticket fields are read
On the ticket side, the query is matched as a substring against the subject, the requester email, the requester name, the requester phone, the tags, and the channel the ticket arrived through.
Ticket comment bodies are searched as well, where the comment store is present. This is the part most people underestimate: the text of the conversation on a ticket is searchable even though the text of a live chat is not, so a phrase you remember from an email thread is findable in a way that the same phrase in a chat is not.
There is one special case worth knowing. If your query parses as a number, it is also matched against the ticket number directly, and a leading hash is stripped first. So both #4182 and 4182 find ticket 4182. This is the fastest path in the whole screen and worth using whenever you have the number.
Which article fields are read
On the knowledge base side, the query is matched against the article title, the full body, the excerpt and the category.
Searching the full body is genuinely useful and has one consequence to keep in mind: a common word will match a great many articles, because it is matching anywhere in the text rather than in a title or summary. Article results are ordered by when they were last updated, most recent first, not by how well they match. The top result is the most recently touched article containing your term, which is not the same as the best one.
Article results are also not filtered by publication status, so drafts appear alongside published articles in the admin view. That is helpful when you are hunting for the half-written article you meant to finish, and worth remembering before you send a colleague a link to something that is not live yet.
How matching actually works
Both sides use plain substring matching. Your query is wrapped and matched anywhere inside the field.
Substring matching has a specific character. It is generous about word fragments, so refund finds refunded and refunds without you asking. It is unforgiving about everything else. There is no stemming beyond that accident, no synonyms, no fuzzy matching and no spelling correction. There is no phrase or boolean syntax either: quotes, AND, OR and minus signs are treated as literal characters to look for, not as operators.
The practical technique that follows is to search for the most distinctive contiguous fragment you can remember, and to search for one thing rather than several. A single unusual word beats a remembered sentence, because the sentence has to appear verbatim.
Ten results, and a total
Each side shows at most ten results, but each side also counts the full number of matches and reports it. That total is the most useful number on the page.
Ten results with a total of eleven means you are nearly looking at everything. Ten results with a total of four hundred means your query is too broad and the ten you can see are simply the most recently updated of a large pile. Read the total before you conclude that what you want is not there, and narrow rather than scroll.
When search says it is unavailable
If a query fails outright, the page shows a short generic message saying search is temporarily unavailable, and the detail is written to the server log instead of the screen.
That is deliberate. Surfacing raw database errors in an admin screen leaks information about server internals to anyone who can reach the page, so the detail deliberately goes somewhere only an administrator can read. If you see that banner, the useful next step is the server log rather than rephrasing the query, and it is worth reporting because it is not a normal state.
How MyLiveChat fits
Once you know the scope, the routing is simple. Use dashboard search for tickets and help articles, and go to the purpose-built screen for everything else.
For conversations, the transcripts screen in your dashboard is the place with real filters over chats, and it can search the things the global box cannot. For someone you remember by name or email, the contacts and visitor screens hold the identity data, and a contact record links out to their history. For a chat that never became a conversation, missed chats and offline messages are their own screens with their own date-bounded searches.
If you regularly need to find text inside chat transcripts, the honest answer is that this box will not do it, and the practical answer is to get the data somewhere that will. Exporting your chat history to CSV or XML covers pulling transcripts out for exactly that reason.
On the article side, remember that admin search and visitor search are different systems answering different questions. What your team finds here has no bearing on what a visitor finds in the widget. Searching your help articles inside live chat covers the visitor-facing path, and finding the help articles that are failing covers the log that tells you what people looked for and did not find. A term that returns nothing for your agents is a decent hint that an article is missing, but the no-results log is the real evidence.
Search reads the dashboard's own records, which is why it can keep working on a day when your settings screens will not load. When your dashboard cannot reach your chat server explains why those two parts of the same dashboard fail independently.