Skip to main content

Who hasn’t seen a user entering an order number or a product number in the menu search bar only to get disappointed that it does not work this way? 

So why not make it possible to search for (the main) objects of our applications this way?

 

Of course performance is key, so I am thinking it should be configured by a developer on what exactly will be searched and with what condition (different from what is configured as global search for each object). 

 

There are countless ways to implement this and how the result could be presented. But by taking Microsoft office as an example, it would be cool if the user could select one of the configured subjects or search in all. 

When clicking on something in the result list, I am expecting that it will open the subject page jumped to/filter on the selected object.

I like this one, always have, especially when you’d have this big pile of data AI can plough through searching for answers.


NewOpen

Hi all, this is currently being designed. As you can see in our roadmap topic, this capability has great synergy with RAG for AI-assistants.

Global search must be subject to both subject and data authorization. The data-authorization part makes reliance on tools and services for indexing, such as ElasticSearch, MS Graph Search API a bit more difficult (but not impossible).

When it comes to matching search terms, we will probably have to take the subjects’ translations into account.

When it comes to individual records, we’re considered relying on the columns tagged subject search configuration, but these settings are generally context-specific (e.g. invoice status or look-up translations) and do not help in identifying individual rows as search targets.

Instead, we are considering the global search to be based on the display value of all entities which have a display value. This automatically excludes link tables and cubes and such which are generally not intended to be a search target.

Perhaps as a developer you’d also want to exclude more, such as weak entities like invoice lines.

And once you’ve found an item, what would you like for it to happen when the user clicks an item? OOTB support can include navigation within your existing navigation structures (menu, details, look-ups) via a shortest-path. Or opening the record as a dedicated document? Maybe kick off a generic process flow for handling a picked search result?

Regarding opening the record as a dedicated document, we’re also considering entities to have an assigned screen type for displaying a single record. This could be used for opening a search result. This screen type can also be applied for quickly opening a document for a specific look-up value (hyperlink) as well as open-document process actions providing a direct filter for a single row.

On the topic of tools, to what extent would you like such a feature to impact your infrastructure or dependency on external services? Relying on external tools or services generally means that data isn’t always instantly indexed, and the global search may lag behind a bit. In turn, there is also support for a certain amount of fuzzyness (typos, partials) or semantic searching. This is not as easy with just a database engine.

We’d love to hear more input on how you’d want to configure global search as a developer.


Updated idea statusOpenMerged
Idea merged into:

All the votes from this idea have been transferred.