I like this one, always have, especially when you’d have this big pile of data AI can plough through searching for answers.
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 statusOpen→Merged
Idea merged into:
All the votes from this idea have been transferred.