Skip to content
CogniYukti

Records

Search in a CRM is a proper-noun problem, not a language problem.

Almost every query is a company or a person, half of them misspelled, a third of them in a language the index was not configured for. Generic full-text search is tuned for prose and quietly fails at all three.

So this one is tuned for the other thing.

Ranking

An exact word beats a near miss, and both are better than nothing.

Two signals rather than one: the word you typed, and how close you got. A record containing the actual word sorts above one that merely resembles it, so searching a company name finds the company before it finds the people in it.

Tolerance is deliberately looser than the usual default, because CRM records are short proper nouns where a three-character slip in a nine-character word is a big proportion of it. On prose that setting would return noise. Here it returns the company you meant.

And there is no word-stemming, on purpose. Stemming helps English prose and actively hurts a list of surnames and brand names in four languages.

Typedsmokco
  • Smoke & Co LogisticsAccount
    …freight brokerage, Rotterdam…
  • Anneke SmitContact
    …Smoke & Co Logistics · Ops Director…
  • Smoke & Co — depot rolloutDeal
    …Negotiation · €88,000…
  • <script>alert(1)</script>Contact
    …rendered as text, every time…
An exact word beats a near miss, so the company sorts above the people in it. And the last row is not a joke — a contact whose name is a script tag renders as text, because the highlighting never hands markup to the browser.
Illustrative
  • Each type of record is searched under its own rules

    So search never shows you something the list would not. Four separate questions, each respecting what you are allowed to see, merged at the end.

  • The highlighting cannot execute

    A match is marked with something that is not markup, and the page escapes the whole result as text before turning the marks into emphasis. A contact whose name is a script tag renders as a script tag, visibly, and does nothing.

  • Punctuation-only input degrades rather than errors

    A query of nothing but symbols falls back to the fuzzy half instead of failing.

  • What people search for and do not find is recorded

    Every search keeps the query and how many results it returned, feeding a report of the most-searched terms that came back empty. Usually the fastest read on what your data is missing.

Honest about the edges

Four kinds of record, a handful of results each.

Search covers accounts, contacts, deals and leads. It does not cover quotes, orders, contracts, tasks, activities, notes or support tickets — those are found from the record they belong to.

It returns a small number of each kind, with no second page and no results screen of its own. It is built to get you to a record quickly, not to be a reporting tool. When the question is genuinely "which ones", that is a report or a filtered list.

  • A search that returns nothing is still useful data

    The zero-result report is usually the fastest read on what your records are missing — the company everybody looks for that nobody ever entered, the product name that exists in three spellings.

  • Analytics can never break the search itself

    The record of what was searched is written inside a guard that rolls back on failure. A reporting table having a bad moment must not stop somebody finding a customer.

Can I save a search?

A search term, yes — named, and yours. Not a filtered view of a list; there are no saved list views anywhere in the CRM yet.

Does it search custom field values?

No. The searchable text is built from the record's own fields. A value in a custom field is visible on the record and is not found by search.

Does it search across the whole platform?

Not from here — this is the CRM's search. Candidates, employees and knowledge articles are searched from their own modules.

When the question is not a name

Ask it in words and get an answer with the records it was built from.