Power Pages with Dataverse search

A Power Pages portal exposing dozens of tables, hundreds of articles, and thousands of cases needs search to be usable. The built-in answer is Dataverse search — the Lucene-based search service powering global search in model-driven apps, exposed to Power Pages through portal-aware components and security trimming.

What Dataverse search provides.

• Full-text indexing of configured tables and columns.
• Relevance ranking across multiple tables.
• Auto-suggest as the user types.
• Faceting — filter by table type, by attribute.
• Security trimming — results respect user permissions.

For a portal, security trimming is the headline feature — anonymous users see public articles; authenticated contacts see public + their organisation's records.

Enabling Dataverse search. At environment level:

1. Power Platform admin centre → environment → Settings → Product → Features.
2. Enable Dataverse search.
3. Wait for initial indexing — depends on table sizes, typically minutes to hours.

Per table, in the table designer:

1. Properties → Searchable: Yes.
2. Search index: add specific columns to index.

Without searchable tables, Dataverse search returns nothing.

Search in Power Pages. The portal exposes search through:

• Search bar component — drop into a page; users type, results display.
• Search page — dedicated full results experience.
• Filtering — facet by table or by attribute.
• Highlighting — matched text highlighted in results.

The component handles security trimming via the portal's authenticated identity (anonymous or contact-bound).

Indexing columns thoughtfully. Index columns users actually search:

• Title, name, subject columns — always.
• Description, body columns — usually.
• Tag/keyword columns — yes.
• Internal IDs, system columns — usually no, unless users search by ID.

Over-indexing inflates the index and slows ranking; under-indexing makes search blind.

Search results security. Power Pages search uses table permissions — the portal-specific access control mechanism. A search result row is shown only if:

• The user has read access to the row through the portal's web role and table permission configuration.
• The row matches the search query.

Anonymous users see only rows accessible to the "Anonymous Users" web role; authenticated users see additionally what their contact's web roles grant.

Auto-suggest. Typing a few characters returns instant suggestions:

• Top 5–10 results.
• Live as the user types.
• Includes top tables to scope to.

The suggestion experience is critical for portal usability — users abandon search if it's slow.

Custom search. For requirements beyond Dataverse search:

• Azure Cognitive Search integration via custom code.
• External search engines (Algolia, ElasticSearch) via integration.
• Liquid templates invoking custom search APIs.

Most portals stay with Dataverse search; custom search is for unusual cases (specific ranking logic, advanced linguistic analysis).

Common pages with search.

• Knowledge base — search KB articles.
• Case lookup — find existing cases.
• Product catalogue — search products.
• Forum / community — search discussions.
• Document library — search uploaded files.

For each, the search page is configured to scope to relevant tables.

Liquid-template integration. Power Pages' Liquid templating language lets you embed search results into pages programmatically — render a featured-results widget on the home page, run a "you might also like" search based on the current page context.

File search. Power Pages supports file attachments on Notes and Document Locations. Dataverse search can index the content of attached files (PDF, Word, Excel, text) — searching for "warranty terms" finds the PDF where the phrase appears. Indexing is asynchronous after attachment upload.

Common pitfalls.

• No initial indexing wait. Search runs against an empty index for a while; users assume it's broken.
• Table permissions missing. A table is indexed but no portal permission; search finds nothing for the user.
• Wrong columns indexed. The user searches by SKU; SKU column isn't indexed; finds nothing.
• Too many tables enabled. Search returns noise; faceting helps but only if the user knows to use it.
• Performance under load. Large portals with thousands of concurrent searches hit indexing limits; Premium capacity may be needed.

Reindexing. When you change indexed columns:

• The index needs to rebuild.
• Power Platform handles rebuild asynchronously.
• During rebuild, results may be incomplete.
• Schedule reindexing for low-traffic windows.

Operational rule. Portal search is the navigation tool users actually reach for after the first day. Tune it: pick the right tables, index the right columns, design search pages that respect security, and monitor search analytics for "no results" patterns that reveal indexing gaps or missing content. A portal whose search "just works" is a portal users return to.