Intranet search: how to help employees find information in Open Intranet

An employee searches for “vacation allowance.” The useful page is titled “Annual leave policy,” but it never appears. After trying twice, they email HR.

That is an intranet search failure, but it does not necessarily mean the search engine needs replacing. The cause could be missing vocabulary, an indexing gap, a restrictive filter, or a result that is difficult to recognize.

When building a new intranet, design search around employee tasks rather than treating it as a launch-day feature. Open Intranet provides a starting point you can configure and extend. The practical goal is to help employees reach the right information faster, while keeping restricted information private.

In this article:

• Why does default intranet search disappoint?
• What must your search index include?
• Which metadata makes information easier to find?
• How should synonyms, boosting, and filters work together?
• How can the search interface help employees choose the right result?
• How can you extend Open Intranet with different search engines?
• How can vector search help employees search by intent?
• How do you measure search success and keep improving it?

Why does default intranet search disappoint?

Search works with the content, fields, access rules, and ranking instructions it receives. It cannot anticipate every organization’s terminology or decide which of several conflicting policies employees should trust.

For the “vacation allowance” query, several things could be going wrong:

• Missing content: the relevant guidance does not exist.
• Vocabulary mismatch: employees and editors use different terms.
• Weak ranking: the policy appears below less useful announcements.
• Stale duplicates: several versions compete with the current policy.
• Permission restrictions: the employee cannot access the expected page.
• Confusing results: the policy appears, but its title or description does not identify it clearly.

These problems need different responses. Changing the backend will not create a missing policy or resolve conflicting versions.

Open Intranet’s search implementation separates the indexed content from the engine that searches it. It uses Drupal Search API, initially with a database backend, and separate indexes for content and user profiles. Employees reach the main search page at /search.

That separation helps you investigate a missing result. First, try opening the expected page with an ordinary employee account. If the page is available directly but absent from search, look at whether it has been indexed and which fields the query searches. If the employee cannot open it, check publication status and access instead. Correctly restricted content should remain absent from their results.

Keep a small collection of queries to return to as you make changes:

Employee query	Expected resource	What to check
Vacation allowance	Applicable annual leave policy	The current policy is easy to recognize
Expense form	Current expense submission page	A retired form does not compete
HR contact	Relevant employee profile	The person appears in the intended search experience
Restricted project name	No restricted result for an unauthorized employee	No title, snippet, or suggestion reveals it

Use the same employee roles each time. This makes it easier to see whether a change has helped, rather than judging search from a single successful query made as an administrator.

What must your search index include?

An index is the searchable representation of your content. A page can exist in the intranet without all its useful information being available to search. That is why coverage is worth checking before adjusting ranking.

In Open Intranet, administrators can inspect the indexes at /admin/config/search/search-api. Compare their included fields and pending items with the sources employees expect to find: policies, guides, people, document records, and any connected repositories.

Search API configuration in Drupal brings together the source, the indexed fields, and processors that prepare information for searching. For example, you might include a policy’s title and body for text matching and its location as a filter. If a required field is missing from the index, changing the wording of the query will not make that field searchable.

Documents need a separate look. Finding a document by its title does not prove that search can read the text inside its attachment. A link to a remotely hosted file does not automatically bring that file’s contents into the index either. Full-text attachment search may require an extraction component, and scanned PDFs may need optical character recognition, or OCR. Treat those as additional setup where they are needed.

Try publishing a new page, updating an existing policy, and retiring an old resource. Check when those changes reach the results. This helps distinguish an indexing delay from a problem with the content itself.

Keep permissions attached to the search experience

Open Intranet’s documented search applies access filtering to its results. In Drupal Search API, content-access processors help carry access information into search. When adding another source, backend, or custom restriction, check that its access rules are represented throughout the search path rather than assuming the new component handles them automatically.

An employee without permission should not discover a confidential document through its title, excerpt, filter value, or autocomplete suggestion. Denying access only after they click is too late if the result has already revealed sensitive information.

Use accounts with different permissions to check both visible results and cached responses. Repeat those checks after changing access rules, not just when setting up search for the first time.

Which metadata makes information easier to find?

Employees should not need to open several files to discover which policy applies to them. Clear titles and a few useful fields let the results explain that difference before someone clicks.

Compare HR_Final_v7.pdf with a page titled “Annual leave policy for US employees,” assigned to the leave topic and marked as current. The second gives both the employee and the search configuration more useful information.

Because Open Intranet is built on Drupal, you can work with fields on the relevant content types rather than trying to fit every distinction into a filename. Review what is already available, then add only what helps a real task:

• Title: words employees recognize.
• Content type: policy, guide, form, news item, or another useful distinction.
• Topic: a consistent category such as leave or expenses.
• Audience or location: where applicability differs.
• Owner: the person or team looking after the information.
• Status: whether it is current or superseded.

The next step is to decide how search uses those fields. In a Drupal Search API index, text fields can contribute to matching, while appropriately configured structured fields can support filtering or sorting. Adding a location field to a policy does not, by itself, create a location filter on the search page: the field must also be indexed and connected to the result interface.

After changing the index configuration, rebuild the affected data where required. Otherwise, older records may not yet contain the values your new filter expects.

Not every field needs to become a filter. Ownership might support editorial maintenance without helping employees narrow their results. Keep the choices manageable for editors, explain how to use them, and fill gaps in existing pages as well as new ones.

A useful check is to show an employee two location-specific policies in the results. Can they identify the right one without opening both? If not, improve the title, field values, or display before adding more categories.

How should synonyms, boosting, and filters work together?

These controls address different problems. Synonyms connect expressions, boosting changes the relative importance of matches, and filters let employees narrow the results deliberately.

Start with the words people actually use. “PTO,” “paid time off,” and “annual leave” may be related, but their meanings can differ between locations. Agree which terms are equivalent before configuring a rule that treats them as the same thing.

For Open Intranet, first look at the fields already indexed and whether the content uses recognizable language. Then assess the weighting options supported by the selected Search API backend. Giving a descriptive title more importance than incidental body text may help a policy rise above an announcement that merely mentions it.

More advanced language handling belongs partly to the search engine. For example, a Solr-backed implementation can use its language-analysis configuration for synonym handling. That is different from editing the policy itself, and it should not be described as a universal Open Intranet synonym screen. The available controls depend on the backend and connector you deploy.

Filters use the structure you established in the metadata. Open Intranet already provides a type filter. A location or topic filter can be added by indexing the appropriate field and configuring it in the search View; a faceted interface may also involve additional modules and backend settings.

Avoid giving every newer page an automatic advantage. A current policy published several years ago may still be the right answer, ahead of last week’s news item.

Change one rule at a time and revisit your example queries. Include wording that should not match, and try filters in combination. If a policy disappears when a location is selected, the problem may be an empty field rather than the search engine.

How can the search interface help employees choose the right result?

A relevant result still fails if the employee cannot recognize it. For a policy lookup, a helpful display might look like this:

Annual leave policy for US employees
Eligibility, annual entitlement, and rules for carrying unused leave into the next year.
Policy · United States · Current

This is a suggested presentation, not a default product screenshot. It gives the employee a quick answer to three questions: what is this, does it apply to me, and is it current?

Open Intranet’s search page is built with Drupal Views. Views brings together the query, filters, sorting, and result presentation. A site builder can review the search View to adjust which information appears and how employees narrow the list. Where results use rendered content rather than individual fields, the relevant display configuration or template also needs attention.

Better Exposed Filters is used for filter presentation in the documented setup. This gives the team a configuration route for changing how available filter choices appear, rather than starting by writing a new interface.

Keep the presentation focused. Show applicability where it helps, use meaningful descriptions, and make people, pages, and documents easy to tell apart. Leave active filters visible and provide a clear way to reset them. When nothing matches, explain how to remove a filter or try a different term instead of leaving an empty page.

Spelling suggestions and autocomplete can be useful additions, but they need their own implementation and access checks. A suggestion drawn from a restricted document can expose information even before the employee submits a search.

Try the completed journey on a phone, with a keyboard, and with relevant assistive technology. People should understand what changed after applying a filter and how to return to a broader set of results.

How can you extend Open Intranet with different search engines?

Open Intranet is not limited to its initial search engine. Its Drupal foundation and Search API integration provide routes to other services without making a whole-intranet replacement the default response.

Think of Search API as the integration layer. It defines the indexed information and provides a way for Drupal to query a supported backend. The backend performs the search, with capabilities that vary by engine and connector.

Search option	Where it fits	What needs consideration
Database-backed Search API	The documented Open Intranet starting point	Coverage, fields, relevance, and performance against actual employee tasks
Apache Solr through Search API Solr	An extension for requirements such as richer language analysis and relevance controls	A configured search service, compatible modules, and ongoing operations
Elasticsearch through a compatible Search API connector	Another integration route, including for teams already operating Elasticsearch	Supported Drupal and Elasticsearch versions and connector functionality
Vector-backed semantic search	Matching meaning where wording differences remain a barrier	Embeddings, retrieval design, provider choice, and permission enforcement

Search API Solr supplies the Drupal connection to Solr. For Elasticsearch, assess the connector requirements for your deployment. These are extension routes, not interchangeable switches with identical feature support.

In a Drupal implementation, changing the backend means configuring the selected search service, connecting the relevant indexes, and populating them. The team then reviews any affected queries, filters, and result rendering. Keeping the employee-facing search page does not remove the need to test what now happens behind it.

Do that work in staging first. Compare the current and proposed setups using the same content, queries, and employee accounts. Look at result usefulness, response time, update delays, and access behavior. Include hosting, monitoring, updates, and recovery in the decision, not just the initial installation.

A different engine is useful when it meets a demonstrated need. It cannot resolve contradictory policies or make a poorly named document understandable on its own.

How can vector search help employees search by intent?

An employee asking “Can I carry unused vacation into next year?” may need a section titled “Annual leave carryover.” Semantic search can help connect those expressions even when the wording differs.

It uses embeddings, numerical representations of text that allow a system to compare meaning. A vector database stores those representations and retrieves similar ones. It is not itself a model that writes answers.

This gives Open Intranet another way to evolve its search through Drupal’s extension ecosystem. Drupal AI Search is one module to evaluate for connecting vector retrieval with Search API. The chosen module, embedding provider, and vector service must be checked for compatibility and production suitability before deployment.

The basic process is to prepare approved text, create its embeddings, store them with references to the source, and retrieve relevant material when an employee asks a question. For long documents, the implementation may search smaller passages so it can find the useful section rather than treat the whole handbook as one item.

Semantic search should complement precision, not remove it. Names, identifiers, and exact policy references still benefit from literal matching. A hybrid approach combines keyword and semantic retrieval to support both kinds of query.

Start with a limited collection and compare it with your tuned keyword search. Include paraphrased questions, ambiguous wording, and exact references. Watch whether employees reach the right source, how long it takes, and what the service costs to operate.

Finding a source and generating an answer are different steps

Semantic retrieval can return relevant links without writing an answer. If you add generated responses, the answer-writing model needs a separate set of controls: applicable source links, a clear response when evidence is missing, and protection against misleading instructions embedded in retrieved material.

Only information the requesting employee is authorized to use should enter the answer-generation context. Checking the visible source links afterward is not enough; restricted information must not leak into the summary in the first place.

Keep access information connected to indexed passages and verify permission handling in the retrieval path. Review caches, document changes, and what happens when an employee loses access. The module’s access mechanisms support that work, but they do not remove the need to validate your particular configuration.

These are extensions to assess for the deployed site, not assumptions about what every Open Intranet installation already includes. Likewise, an editorial AI assistant and employee-facing semantic search are separate capabilities.

How do you measure search success and keep improving it?

Search success means completing a task, not merely returning results. Start with measures that help you understand the employee’s experience:

Measure	What it helps you understand
Task completion	Whether employees reached the correct resource or answer
Time to the right resource	How long a defined lookup takes
Expected-result placement	Whether the intended resource appears prominently
Zero-result rate	How often queries return nothing, considering filters and account context
Query reformulation	Whether employees repeatedly change wording before finding something

Establish a baseline before changing configuration. Observe actual tasks before choosing targets, rather than borrowing a benchmark that may not fit your organization.

For an Open Intranet site, the search View is a useful starting point for discussing measurement with the analytics owner. Review which query, filter, result-click, and empty-result events are already captured and what additional tracking is needed. Search API configuration and analytics reporting serve different purposes; an index status page is not a report of employee success.

When results disappoint, group the causes: missing content, indexing faults, vocabulary gaps, restrictive filters, or legitimate access limits. That helps send the problem to someone who can fix it instead of treating every failed query as an engine issue.

A click does not prove success: the employee may have opened the wrong document. Equally, a helpful excerpt may answer the question without a click. Pair aggregate analytics with short conversations and task tests, and limit query-log access and retention because people may type sensitive information into search.

Keep responsibilities simple. Content owners correct the source material, a search owner looks after relevance and configuration, and the technical team monitors indexing and failures. Reuse the same queries and employee roles after changes to fields, engines, permissions, or result displays.

This makes improvement a repeatable part of maintaining the intranet, rather than a one-off search redesign.

Ready to make Open Intranet search more useful?

Start with a few difficult employee queries, the answers people should reach, and your current Open Intranet setup.

Bring them to a search review with Droptica, the team behind Open Intranet. We can help separate content fixes from configuration changes and extension work, while keeping your organization’s access rules central to the design.

Contact Droptica to review your search priorities and define what to test first.