Search API Group Access Reaches 1.0.0 for Drupal Search and AI Retrieval

Search API Group Access reached its first stable release, version 1.0.0, on 8 November 2026, after a September beta. The contributed Drupal module adds Group permission conditions to Search API queries before the backend selects and ranks results, including searches used to retrieve material for AI assistants.

The release addresses a gap between Drupal's content access system and search backends. The Group module enforces permissions through entity query alterations, but searches performed through Search API can use separate backends that do not apply those checks. As a result, restricted content may remain in the initial search results even when later entity access checks remove it from the displayed list. Result counts, facets and pagination may therefore include items an account cannot view. Search API Group Access applies the relevant conditions inside the search backend before ranking takes place.

The stable release notes confirm that the module's code remains unchanged from version 1.0.0-beta1, released on 24 September 2026. Project maintainer José Fernandes, founder and CEO of Bloomidea, published the stable release with documentation updates and confirmed test coverage on Drupal 10 and Drupal 11. The module is compatible with Drupal 10.3 and later within the Drupal 10 series, and Drupal 11. Drupal.org also confirms that stable releases of the project are covered by its security advisory policy.

The module introduces a Group access processor for Search API indexes. During indexing, it records information about an item's group relationships, ownership and publication status. When a search runs, it checks the account's current Group memberships, roles and permissions before adding the appropriate filtering conditions. Membership and permission changes therefore take effect on the next search without requiring a complete reindex, while changes to group relationships queue affected items for reindexing.

The integration also responds to a problem discussed in the Drupal community for several years. A Group issue opened in February 2021 documented how Search API could return content inaccessible to the searching account. Another issue raised in September 2025 demonstrated incorrect facet counts when Group access restrictions were not applied to indexed search results. Contributors discussed implementing a Search API processor to address the difference between Group's database-query access checks and indexed searches.

The module also supports searches using AI Search, which can retrieve content from vector databases for AI-assisted answers. Bloomidea described its own implementation in a technical article. According to the company, its intranet uses AI Search with Qdrant to retrieve information from approximately 270,000 items. The Group access processor restricts the candidates available to the search backend before it selects and ranks results, using the requesting account's current Group permissions. This is a retrieval filter, not a guarantee about how an AI assistant handles or presents its answer.

Bloomidea also reported performance measurements for a separate Qdrant index containing 190,000 points. According to the company, filtered searches took between 100 and 210 milliseconds without payload indexes, compared with two to 16 milliseconds after the relevant fields were indexed. These are implementation-specific measurements reported by Bloomidea rather than independently verified benchmarks.

Site builders must enable the Group access processor on the relevant Search API index and reindex its content. The module requires Group 3.3 or later and Search API 1.39 or later, along with a backend supporting the required condition groups and filters. For AI Search indexes, the access-related fields must be configured as filterable attributes; the project documentation specifies three such fields and recommends Qdrant payload indexes for efficient filtering. The module's documentation also describes how to populate access information before activating filtering on an existing large index.

The module has documented limitations. It applies Group's entity view access rules but does not cover Group entities themselves or other access operations. A content item belonging to two groups may also be excluded from search results even when Group would otherwise allow access, if the account's permissions differ between the two groups. The maintainer describes this as an accepted false negative intended to avoid returning inaccessible content.

Another limitation concerns indexed field values. Although the processor filters which content items are returned, it does not separately restrict every field associated with an otherwise accessible item. As Fernandes explained in the Group integration discussion, a facet based on an article's group associations may still display information about a group the account cannot access. The release therefore addresses Group-aware filtering of search results, but does not establish that every indexed field or AI application output is independently access-controlled.