Good Morning Vincent.
The search-process is a hard coded one. And when you want to get that changed in any way, please open an Idea for this here after.
In the Idea, then please explain in as much detail as possible what you would like to see/get, when possible, in a future release of the product.
Please see the following information, related to the 'Search' in the SC-UI and USS-UI.
Based on the latest analysis results, we have confirmed that the "Entire Catalog" search feature is working as per design.
The "Entire Catalog" search feature will search for the search input/string across:
offering names, offering descriptions, service option group names, service option group descriptions and service option element item texts.
As per the design, it is just a raw string search, instead of a very intelligent search that will interpret what the users may want to search, nor it will do machine learning.
There is no configuration feature that administrators can apply to control the search results.
In other words, the more specific search input/string you input for the "Entire Catalog" search, the better the search result will be.
In addition, after the the "Entire Catalog" search results are returned, on the top of the UI, you will see a drop list, and "Entire Catalog" is listed by default.
You may drill down the search results by choose the subcategory for the further search that should produce a more target and specific results.
...
As an example, searching for 'visio'.
What I mean by "raw string search" is, for ANY information containing the string, 'visio', the results will be returned.
Even the words like division, vision, etc will be picked up as they contains the string visio.
The last three items which do not visually contain the string visio in this UI, and nothing is highlighted because the string visio contains in the description.
...
The SQL statement executed for retuning the results is a fairly complex statement with multiple left outer join,
case when else and selects for constructing the final results pulling the data from multiple tables.
The order of the results show on the UI based on the actual orders returned from the database.
There is no specific criteria for ordering.
As explained, this is working as per design.
Please let me know if you have further questions regarding this, if not, we will go ahead to close this issue.
...
The additional items in the drop list will only show up for the search string which is part of the offering folder name.
For examples, with the out of the box offerings, search for "server", you will see "Server Software" in the drop list;
search for "email", you will see "Email", "Email Distribution Lists", and "Email Forms" in the drop list;
search for "reports", you will see "Application Reports", etc
You can also search using the search box shown in the below screenshots for searching in a smaller set of offerings.
The query that is being executed when you use the 'search' function is the following.
Which represents the 'logic' for the 'search' that you asked for in this issue.
It will search for all the occurences of query string in Offering name, rate plan name and rate definition item text.
Example query:
select path,o.offering_id,item_id,rp.rate_plan_id,
case when ( o.offering_name collate database_default like ?
OR o.description collate database_default like ? )
then 0
WHEN ( rp.rate_plan_name collate database_default like ? )
then 1
WHEN ( dbo.usm_fn_remove_html(rd.item_text) collate database_default
like ? OR rd.item_id in ( 12538,12571,12500,12577 ) )
then 2 else 3 end as search_source,
case when ( rd.rate_col != 0 )
THEN (select item_id from usm_rate_definition
where rate_col=0 and rate_row = rd.rate_row and status = 1
and rate_plan_id = rd.rate_plan_id)
else rd.item_id end as item_id
from usm_offering o
left outer join usm_offering_ratedef_inclusion ordi
on ordi.parent_id=o.offering_id
or ordi.parent_id=o.top_base_offering
left outer join usm_rate_definition rd
on ordi.child_id=rd.item_id
left outer join usm_rate_plan rp
on ordi.rate_plan_id=rp.rate_plan_id
where o.domain='ca.com'
and (o.path like '10001/%' or o.path like '%/10001/%' )
and ( o.offering_name collate database_default like ?
OR rp.rate_plan_name collate database_default like ?
OR rd.item_text collate database_default like ?
OR o.description collate database_default like ?
OR rd.item_id in ( 12538,12571,12500,12577 ) )
Here ? will be updated with query string:i.e. %service% or %service desk%
It is a complicated one, I agree with you on that.
A related document is shown below:
https://support.ca.com/us/knowledge-base-articles.tec1277094.html
Kind regards, Louis van Amelsfort.