What is enterprise search?

Enterprise search finds records inside a company, across the systems they live in, and shows each person only what they may open. It is also called an internal search engine. The search box in a single system, such as a ticketing tool, covers that system alone. Enterprise search sits across all of them.

IBM’s explainer defines it as “the retrieval of relevant information from disparate data sources throughout an organization.” It also separates it from federated search, which sends one query to several systems at once and combines what each returns. An enterprise search engine usually gathers every source into an index of its own. That raises the question this article keeps returning to: what the index copies, and how it stays current.

Web search ranks public pages that anyone may read. Inside a company, five things change.

• Many systems. A question about one part can touch tickets, part records, manuals, supplier notices and field reports, each in its own system and format.
• Permissions per record. Two engineers can type the same query and be allowed different results. The source system decides who may read a record, and search has to agree with it.
• Identifiers. A technician types A320-2741-08. There is one right answer, and a near miss is the wrong part on the line.
• Acronyms. Records are written in the company’s own vocabulary: program names, reference numbers, abbreviations nobody outside uses.
• Freshness. Records change every day, and so does access. A result that was right last week can be outdated or forbidden today.

The intent differs too. IBM’s explainer makes the point: people searching at work are often after highly specific information that exists in only one place. A web search can settle for any good page. An engineer needs the one maintenance log that describes this fault.

An enterprise search engine does four jobs, in this order.

• Connect. Connectors read each source system: its records, the links between them, and who may read each one.
• Index. Text is pulled out of files, scanned pages are read, and identifiers are kept intact so they can be matched exactly.
• Retrieve. The query runs against the index as the person who asked. Records they may not open are removed before anything is ranked.
• Rank and show. What remains is put in order, and each result links to the record in its source.

Retrieval is not one technique. Our whitepaper Modern enterprise search splits it into six layers, each building on the last. Keyword search matches the words in the question. Fuzzy search allows for typos. Vector search matches meaning, so a description finds a record written in other words.

Hybrid search ranks exact and close matches in one list, which What is hybrid search? explains. Graph retrieval follows the links between records: a part, the notice about it, the tickets it caused. Agents call the other five as tools.

In an industrial company the answer is often written down already: a closed ticket, a maintenance log, a supplier notice. When search cannot find it, people ask a colleague, open five systems, or do the work again.

Airbus Customer Services had more than forty years of technical history across CRM systems, network drives and engineering databases. Its acronyms, reference numbers and aircraft programs defeated ordinary search, as the Airbus story describes.

Search also sits under every AI assistant and agent that answers from company records. An agent asked about delays on a production line does not search once. It finds the delayed orders, then the parts on them, then the supplier notices about those parts. Each step is a search, so the agent is only as good as the search it calls.

Oversharing. A search engine that honors permissions shows each person everything they may open. That includes files that were shared too widely years ago and never noticed. Microsoft’s Copilot documentation says Copilot “only surfaces organizational data to which individual users have at least view permissions.” That is the correct behavior, and it is why Microsoft’s deployment blueprint for Copilot names remediating oversharing as its first step.

Stale permissions. An index that copied access rules when it read a record keeps them until it reads the record again. If someone loses access in the source system, the index can keep showing them the record until the next sync. Ask how long that gap is, and whether a change in access needs a full reindex.

Copies with their own rules. Every extra index is another place where access is defined. A separate store for vectors, with its own permission model, has to be kept in step with the first. Rules also combine in ways people miss. Elasticsearch gives a user with several roles the union of them: per its documentation, “only one of the role queries must match for a document to be returned.”

Near misses. A query for a part number that is not in the index should return nothing and say so. A list of close matches with no warning invites someone to pick the wrong part.

Test it with your own questions, as your own users. Five checks cover most of what goes wrong.

• A judged set of real queries. Take 80 to 120 queries from search logs, searches that found nothing, and known failures. People who know the records mark the right answers by record id. Measure the ranking before and after every change, as our post on measuring search relevance describes.
• The same query as different people. Run each query as users with different access. A result one of them should not see is a failure, whatever its rank.
• Time to revoke. Remove someone’s access in the source system and time how long the record stays findable.
• Identifiers. Search for exact part numbers, and for one that does not exist. The first should come back on top, and the second should come back empty.
• Explanations. Pick a result and ask why it ranked where it did. When someone disputes an answer, you need to show the record it came from.

For the ranking itself, NDCG at 10 is a common measure: it rewards putting the best records in the first ten results.

In Curiosity Studio, connectors bring records from more than 70 systems into one typed graph, with the links between them. Access is synced from the source systems and checked per record at query time, so a person only sees what the source would show them. A revoked access applies on the next query after the connector syncs it, with no reindex.

Keyword, vector and graph search run in one query on the same graph, and every result carries the record it came from: see search for developers. The vectors are stored beside the records, so there is no second store with its own permissions. A system with no built in connector, such as a SQL database, needs a connector you write with the connector SDK.

The Modern enterprise search whitepaper takes the six layers apart, and the Trust Center lists the security controls around them.