Unified search engine, unified search app and unified search software that bring every company tool into one query

Unified search works in five steps: connect to each source, normalize what comes back into one document model, build a single index, filter that index against the searcher's permissions at the moment they ask, and then generate an answer from what survived the filter. The first and fourth steps are where products differ, and where most of the engineering cost sits.

Connectors do more than fetch content. A good one also fetches the access control list attached to every item, tracks deletions rather than only additions, and handles the pagination and rate limits of an API that was never designed for a full corpus export. Connectors are also the part that ages: SaaS vendors change APIs, deprecate endpoints and alter permission models, and a connector that silently starts returning less is far more damaging than one that fails loudly, because the index simply gets quieter and nobody notices for weeks.

Normalization is the unglamorous step that decides result quality. A Slack message, a Google Doc, a Jira ticket and a Salesforce record have almost nothing structurally in common, and ranking them against each other requires mapping them onto shared fields: title, body, author, timestamp, source, permissions. Do that badly and the index ranks a chat message above a signed policy because the chat message happened to repeat the query terms more often.

These three are often discussed as if they were the same product with different marketing. They are genuinely different architectures with different failure modes, and knowing which one a vendor is selling you tells you most of what you need to know about how it will behave in year two.

Most serious workplace deployments end up on the unified index, because coherent cross-source ranking is the thing people actually wanted and federation cannot deliver it. The trade you accept is that you now have a copy of company content in one place, which raises the stakes on access control considerably.

Four things, reliably. Permission drift, where a revoked access does not take effect until the next sync and someone gets an answer built from a document they were removed from. Stale content, where a deleted or superseded document stays in the index because the connector tracks additions better than removals. Duplicate content, where the same policy exists as a Drive PDF, a Confluence page and a pasted Slack message, and the answer cites whichever copy indexed best rather than whichever is current. And connector rot, where an API change quietly narrows what one source returns.

Only the first of those is a security problem, and it is the one to press vendors hardest on. The honest question is not "do you respect source permissions", because every vendor says yes. It is "at what moment do you check them". Checking at sync time means your exposure window is the length of your sync interval. Checking at query time means a revoked permission takes effect on the next question asked. InSearch inherits item-level permissions from every source and enforces them live at query time for exactly this reason.

The other three are quality problems, and they are the reason unified search deployments are judged as failures more often than they technically fail. Nobody files a ticket saying the index is stale. They just stop using the search box and go back to asking a colleague, which is the outcome the project was funded to prevent.

Bring your own hard question to the demo. The single most useful evaluation technique is to ask a question whose answer is genuinely split across three systems in your company, ideally one where a decision lives in a document and the exception to it lives in a chat thread. A tool that returns the document but misses the exception is doing app-native search with a wider net, not unified search.

Beyond that, five questions separate products quickly. Are permissions enforced at query time or at sync time? Does every claim in an answer carry a citation to a specific document, or does the tool cite a source list at the bottom? What happens when the answer does not exist in your content, and does the tool say so or invent something? How is the product priced, per seat or per query or per record indexed, and how does that behave when adoption succeeds? And is my content used to train models, in writing, in the contract rather than in the marketing copy?

It also pays to check what the vendor publishes. A surprising number of enterprise search vendors publish no pricing at all, which turns any comparison into a sales cycle before you can even build a shortlist. Our enterprise search tools comparison lists sixteen products alongside whether each one publishes a price, and the Coveo vs Lucidworks comparison covers the platform end of the market, where you are buying relevance machinery rather than a finished product.

Connecting sources takes minutes per app when the product uses OAuth against SaaS APIs. Initial indexing takes hours to days depending on corpus size. Getting genuine company-wide adoption takes considerably longer than either, and that is the part worth planning for.

The pattern that works is to start with two or three sources that cover a real, recurring question, prove it with one team, then widen. Starting with every connector switched on at once produces a large index, a long first crawl and no clear success measure, which makes it hard to tell whether the tool is working. Starting with the questions your help desk or your HR lead answers repeatedly gives you a before-and-after you can actually point at.

Platform products behave differently here. If you are evaluating something you have to build on rather than connect, add the engineering time to design the search experience, tune relevance and operate the index. That is often measured in quarters rather than days, and it is a reasonable investment when search is part of what you sell to customers, and a hard one to justify when it is internal plumbing.

No, and treating it as a replacement is a common way to waste a year. Unified search reads what already exists; it does not create or curate content. If the answer to a question was never written down anywhere, no search layer will produce it, and the honest result is that nothing was found.

What unified search does replace is the requirement that everything be written down in one place. The traditional knowledge base project asks people to migrate and maintain content in a system they do not otherwise work in, which is why so many of them decay. A unified layer removes that requirement: the Slack thread, the Drive doc and the Jira ticket stay where they were created, and search treats them as one corpus.

The useful role for an intranet or knowledge base alongside unified search is authority. When five documents disagree, someone has to decide which one is current, and that is a governance job rather than a search job. Search can tell you the five documents exist and cite each one, which is usually the first time anyone notices the contradiction. Our knowledge management software page covers that governance side, and intranet search engine covers the case where the intranet is only part of the answer.