Configure cross-project search

With cross-project search (CPS), users in your organization can search across multiple Elastic Cloud Serverless projects at once, instead of searching each project individually. When your data is split across projects to organize ownership, use cases, or environments, cross-project search lets you query all the data from a single place.

Cross-project search is the Serverless equivalent of cross-cluster search, with a few differences and enhancements:

• Setting up cross-project search doesn't require an understanding of your deployment architecture or complex security configurations.
• Permissions stay consistent across projects, and you can always adjust scope and access as needed.
• Searches are performed across projects by default, reducing the need to refactor your queries as you link additional projects.

This section explains how to set up and manage cross-project search for your organization, including linking projects, managing user access, and refining scope. For information on using cross-project search, including syntax and examples, refer to Cross-project search.

Cross-project search runs across origin and linked projects within your Elastic Cloud organization:

• Origin project: The base project where you link projects and run cross-project searches.
• Linked projects: The projects you connect to the origin project. Data in the linked projects becomes searchable from the origin project.

Projects are intended to act as logical namespaces for data, not hard boundaries for querying it. You can split data into projects to organize ownership, use cases, or environments, while still expecting to search and analyze that data from a single place.

After you link projects, searches from the origin project run across the origin and all linked projects by default. This default behavior provides a consistent experience for querying, analysis, and insights across linked projects. Restricting search scope is always possible, by explicitly scoping the search request using qualified expressions or project routing parameters.

Administrators can also adjust the search scope by configuring the CPS scope for each space. For best results, set this space-level default before you link projects.

For details about project IDs and aliases used in search expressions, refer to Project IDs and aliases.

Before you configure cross-project search, review these prerequisites and best practices:

• You must be an organization owner or project administrator:
  • Organization owners can link any projects within the organization.
  • Project administrators must have admin access on both the origin project and each linked project.
• Your origin and linked projects must meet certain requirements.
• Consider the architecture patterns and choose the right linking topology for your organization.

To be available for linking, projects must meet the following requirements:

• The origin project and all linked projects must be in the same Elastic Cloud organization.
• You can link any combination of Elasticsearch, Elastic Observability, and Elastic Security projects in the same organization.
• Elastic Security Serverless and Elastic Observability Serverless projects require the Complete feature tier. Projects on the Essentials tier are not compatible with cross-project search.

Only compatible projects appear in the cross-project search linking wizard. If a project you expected to link to is missing from the list, it might not meet the requirements, or you might not have the necessary permissions on the project.

When configuring cross-project search, consider how the CPS architecture (or linking pattern) will affect searches, dashboards, and alerting across your organization. Cross-project search supports three patterns, each with a different level of operational risk.

For most deployments, we recommend creating a dedicated overview project that can act as an origin project. You can also think of this as a hub-and-spoke model.

In this architecture, you create a new, empty project and link existing projects to it. You run all cross-project searches from the new overview project, while your actual active projects continue to operate independently. The linked ("spoke") projects are not linked to each other.

The overview project becomes a central point for broad searches, dashboards, and investigations, without affecting your existing setup.

The overview project model is strongly recommended and appropriate for most CPS configurations. These additional patterns are valid, but they involve additional risk and require careful configuration:

• Shared data project (N-to-1): A single project stores data from a shared service (for example, logs). Multiple origin projects link to this central data project.

  The N-to-1 pattern is often used when several teams need to query shared data independently. The main risk is that linking to a shared data project affects searches, dashboards, and alerts in each origin project. If the shared project is a large, active project, the expanded dataset might cause unexpected behavior. If you're using this pattern, make sure to manage user access and consider CPS scope.

• Data mesh (N-to-N): Multiple active projects link directly to each other.

  The N-to-N pattern is the most complex and involves the highest risk. After you link projects, all searches, dashboards, and alerting rules in each origin project will query data from every linked project by default, which might make workflows unpredictable. Make sure you check alerting rules, which might be applied to data that the rule was never intended to evaluate.

After reviewing the architecture patterns, you can configure CPS scope and manage linked projects. For best results, complete these tasks in order:

1. Set space scope defaults: Configure the default cross-project search scope for each space that will be used with cross-project search.
2. Manage user access and programmatic access: Confirm user roles in both the origin and linked projects, as well as roles granted to Elastic Cloud API keys that will be used with cross-project search.
3. Link and manage projects: Link projects in the Elastic Cloud UI, manage linked projects, and unlink projects.

Make sure to also review the feature impacts and limitations of CPS.

Cross-project search billing varies by project type:

When CPS becomes generally available, all project types will also incur a charge for data moved between projects. Exact rates and billing mechanics will be provided closer to GA.

When you link projects for cross-project search, the expanded dataset can affect existing features in the origin project.

• Alerts: By default, rules in the origin project run against the combined dataset of the origin and all linked projects. Rules tuned for a single project's data might produce false positives when they evaluate a larger dataset. This is one reason we recommend using a dedicated overview project, so that existing rules on data projects are not affected. Make sure to also consider the default cross-project search scope for each space, or save explicit project routing on individual rules.

• Dashboards and visualizations: Existing dashboards and visualizations in the origin project will query all linked projects by default. To control this, set the default cross-project search scope for each space, or save explicit project routing on individual dashboard panels.

• User permissions: Cross-project search results are filtered by each user's role assignments across projects. Users with different roles will see different results from the same query. Refer to Manage user access.

• Painless scripting: The Painless execute API does not search across linked projects. It resolves index names against the origin project only. You can target a linked project by prefixing the index with the project alias (for example, projectAlias:myindex).

Cross-project search has the following limitations:

• Maximum of 20 linked projects: Each origin project can have up to 20 linked projects. A linked project can be associated with any number of origin projects.
• System indices: Indices such as .security and .fleet-* are excluded from cross-project search results by design.
• New projects only: During technical preview, only newly created projects can function as origin projects.
• Anomaly detection and transforms: During technical preview, ML anomaly detection jobs and transforms are not supported with CPS. They continue to run on origin project data only.
• Data frame analytics analytics jobs: data frame analytics analytics jobs are not supported with CPS. They continue to run on origin project data only.
• For ES|QL limitations specific to CPS, refer to ES|QL with cross-project search.

• Additional limitations apply to Elastic Observability and Elastic Security projects.

Elastic Security apps have limited CPS support:

• Timeline: Only the ES|QL tab supports SET project_routing. All other Timeline tabs search the origin project only.
• Other Security features: The Explore page, threat-hunting workflows, the alert details flyout, and entity store remain scoped to the origin project.
• Alerting: During technical preview, rules that query data across linked projects can generate alerts, and you can view those alerts in the UI. However, the alert response workflow, which includes actions after an alert is raised, such as triage, investigation, and case management across linked projects, is not yet fully supported with CPS.

Observability apps have limited CPS support. The scope selector is not available in Observability apps, and most apps remain scoped to the origin project.

For specific app details, refer to Cross-project search in Observability.

After you configure cross-project search and link projects, users can start searching across linked projects from the origin project. For search syntax, scope controls, and examples, refer to the following pages:

• Cross-project search overview: Learn how to build queries in a CPS context, including how to restrict search scope.
• Managing cross-project search scope in your project apps: Learn how CPS works with compatible Kibana apps, including how to adjust search scope.