Feature Request: Improve Console Search Ranking and Matching Logic
under review
T
Timothy Cogar
Issue
Lightspeed Filter console search currently appears to rely heavily on substring matching.
This means a search term may return records containing the entered character sequence anywhere within the value, even when a more relevant record begins with or exactly matches the search term.
For administrative workflows, this makes search results unnecessarily difficult to interpret and can bury the intended result among less relevant matches.
Current Behavior
Search appears to treat any matching character sequence as a valid result without sufficiently prioritizing where that match occurs.
For example, a search for:
Wake
should prioritize:
Wake County
Wake Forest High School
Wakefield Middle School
before records where the same sequence appears only later within the value.
Likewise, an exact match should always rank above a partial match.
Preferred Search Logic
Console search should rank results using a predictable relevance hierarchy.
Recommended order:
Exact match
Exact identifier match
Starts-with / prefix match
Word-boundary match
Relevant partial match
General substring match
Substring matching can remain available, but it should be the lowest-priority matching method rather than the primary ranking behavior.
Operational Impact
Poor search relevance increases administrative effort when locating known records.
This can affect searches for:
users;
groups;
schools;
policies;
devices;
categories;
Access Lists;
synchronized objects;
other administrative records.
Administrators often already know the beginning or exact value of the object they are trying to locate.
In those cases, the console should prioritize the most probable intended result rather than presenting loosely related substring matches first.
Requested Enhancement
Update console search behavior so that results are ranked by relevance.
At minimum:
exact matches should rank first;
prefix matches should rank ahead of internal substring matches;
searches for complete identifiers should return the matching object prominently;
broad substring matches should remain available after higher-confidence results;
the ranking behavior should be consistent across console areas using the same search component.
Optional Search Controls
If Lightspeed intends to preserve broad substring matching as the default behavior, support for simple search controls or syntax would also address the issue.
Examples could include:
exact-match search;
starts-with search;
quoted search terms;
field-specific search;
search operators.
Advanced syntax is not required if the default ranking behavior itself is corrected.
Consistency Requirement
Where the same search component is used across multiple Lightspeed Filter console areas, the matching and relevance logic should behave consistently.
An administrator should not need to learn different search behavior depending on which console page is being used.
Requested Outcome
Provide console search behavior that prioritizes the record an administrator is most likely attempting to locate.
The goal is not to remove partial search capability.
The requested model is:
Exact and prefix matches first → broad substring matches afterward
rather than treating all substring matches as similarly relevant.
Acceptance Criteria
This request would be considered addressed when:
Exact matches appear before partial matches.
Prefix matches appear before internal substring matches.
Search results are ordered according to relevance.
Known identifiers can be located without reviewing unrelated substring results.
Search behavior is predictable and consistent across applicable console areas.
Broad substring searching remains available without reducing the visibility of stronger matches.
Business Value
Improved search relevance would:
reduce time spent locating administrative records;
improve console usability;
reduce unnecessary search retries;
make troubleshooting more efficient;
improve consistency across administrative workflows.
The requested change is fundamentally a ranking improvement:
Prefer the strongest match, not merely any match.
Matthew Burg
updated the status to
under review