Hi @Arie V,
A few years ago I made a prototype for this feature for my graduation internship research project.
So we are definitely interested in adding such a feature. 
It's on the backlog for the Universal GUI, we don't have a planning for when it will be worked on however.
Kind regards,
Leroy Witteveen
To take this idea another step further: how about actually using the Office 365 Search box and integrating the Thinkwise data into the Office 365 Search using the Search API through Microsoft Graph? For inspiration and references check this podcast and this Microsoft documentation. Microsoft offers connectors to Microsoft SQL server and Azure SQL databases and third-party offerings include AWS and Google SQL databases too.
I am pretty sure that the vast majority of the Thinkwise customers uses Office 365 and I believe this could be a great potential solution to:
- Leverage the Search capabilities of Microsoft (so no need to develop all of this from scratch yourselves)
- Better integrate Thinkwise with productivity & collaboration tools
Two years ago..is this still on the backlog? It would be a great feature!
The following idea has been merged into this idea:
All the votes have been transferred into this idea.
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.
