Managing cross-project search scope in your project apps

When cross-project search (CPS) is enabled and projects are linked, searches initiated from your project's apps run across all linked projects by default. Kibana provides several ways to narrow or change this scope:

• Space default: Admins configure a default scope for each space, which applies when you start a new session.
• Session scope: Use the CPS scope selector in the project's header to change which projects are searched during your session.
• Stored scope: Some features use the scope selector to set a project routing value that is saved with a specific resource, such as a dashboard. The stored scope applies every time that resource runs or opens, independent of the session scope.
• Query-level override: Use project routing or qualified index expressions in individual queries to target specific projects.

The Cross-project search (CPS) scope selector ( ) lets you choose which linked projects to include. It appears in the project header, or on the resource you are creating or editing.

The scope selector lists all linked projects, narrowed by any active tag filters. The origin project always appears first, labeled This project. Each project row shows the project name, project type icon, and any assigned tags.

From the scope selector, you can:

• Toggle individual projects on or off to include or exclude them from searches.
• Filter the project list by tags to find and select projects based on metadata or custom tags.

The footer displays the count of included and excluded projects.

The scope selector is not editable in every app. Some apps display it as read-only, meaning the app uses the space default scope but you cannot change it. In read-only mode, filter badges are visible but you cannot create, edit, or remove filters. Other apps show it as unavailable, meaning the app searches only the current project. Refer to Cross-project search availability by app for details.

When the current selection matches the space default, the scope selector displays a Using space defaults indicator. When you change the selection, the indicator disappears. To restore the space default at any time, select Revert to space defaults in the scope selector. Changes you make in the project header or on a resource do not change the space default.

The scope selector also provides shortcuts to admin settings. Select Adjust space defaults to open the space's CPS scope configuration, or Manage cross-project search to open the CPS management page.

Sometimes, you might want to change which projects are included in your results as you work. Other times, you want to set the project scope and persist it with a resource to keep inputs consistent. Session scope and stored scope are how apps make that happen. The behavior follows the app.

Most apps use session scope. Session scope is which projects are searched while you work. You set it with the scope selector in the project header. Your selection is preserved as you navigate between apps that support the selector. Starting a new session resets to the space default. Session scope is used by most apps.

Some apps use stored scope. Stored scope is saved with a resource and applies every time that resource runs or opens. Some apps, such as Dashboards, save a snapshot of the scope currently set in the header selector.

In apps where you write queries, you can still override that scope at the query level.

Refer to the availability table for how each app uses scope.

Each project row has a toggle switch that includes or excludes it from searches. You can also use the context menu on any project row for quick actions:

• Include only this project: Excludes all other projects currently shown in the list.
• Exclude only this project: Includes all other projects currently shown in the list except this one.

You can also select all projects currently shown in the list by clicking Include all visible.

The scope selector prevents you from excluding every project. The toggle on the last included project is deactivated, so at least one project is always included.

If your current selection results in zero included projects, the scope selector displays a warning.

You can narrow the project list in the scope selector by creating tag filters. Tag filters let you find and select projects based on predefined and custom project tags. Predefined tags include _type, _region, and _csp. You can also filter on custom tags that you define in the Elastic Cloud UI.

To add a tag filter:

1. Open the scope selector and select Add project tag filter.
2. Choose a tag from the Select a tag dropdown.
3. Choose an operator. The default operator is is.
4. If the operator requires a value, choose one or more values from the Select a value dropdown.
5. Select Apply ( ) to add the filter.

When multiple filters are active, they are combined with AND logic: a project must match all filters to appear in the list.

Active filters appear as badges below the filter form. You can:

• Select a filter badge to edit its tag, operator, or value.
• Invert a filter to switch between include and exclude logic.
• Turn off a filter without removing it.
• Remove a filter to delete it.

To remove all active filters at once, select Clear project tag filters in the scope selector.

You can create a filter directly from a project's tags. Select the tag count badge on a project row to open a popover listing that project's tags, then select a tag to create a filter for it.

How newly linked projects affect your scope depends on your app.

In most cases, your scope is saved as a project routing expression, not a fixed list, so it also applies to projects that are linked later:

• Projects that match your active tag filters are included automatically.
• Excluding a project individually affects only that project.

To keep future projects out of your scope, use a tag filter rather than excluding projects one by one.

In apps where you write queries, you can define a different cross-project search scope than the one set in the header's scope selector or the space-level default. This is useful when you want a specific query or dashboard panel to search a different set of projects.

There are two main mechanisms:

• Project routing: Use a project_routing parameter to limit which projects a query runs against. In ES|QL, use SET project_routing at the beginning of your query. SET project_routing overrides the space default, the header selection, and any dashboard-stored scope for that query. Project routing is evaluated before query execution, so excluded projects are never queried.
• Qualified index expressions: Prefix an index name with a project alias to target a specific project, for example my_project:logs-*. Qualified expressions work in index patterns and query source commands.

For example, to search only a specific linked project from Discover, start your ES|QL query with:

SET project_routing="_alias:my-project";
FROM logs-*
| LIMIT 100
		

Not all apps support cross-project search. The following table shows which apps support the CPS scope selector and query-level overrides. Any app with an ES|QL editor supports SET project_routing and qualified index expressions in FROM commands.

The header's CPS scope selector is not available in other apps, including Transforms, Canvas, and object listing pages.

Observability apps have limited CPS support. The scope selector is not available in Observability apps, and most apps remain scoped to the origin project. The following table shows how each Observability app behaves with CPS:

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

Elastic Security apps have partial CPS support. The following features work across linked projects:

• Timeline: Tables display documents from linked projects. Actions that don't apply to remote documents are disabled.
• Alert, event, and attack flyouts: Flyouts render correctly for documents from linked projects. Remote documents are clearly identified, and actions that don't apply to remote documents are hidden or disabled. Investigate in Timeline remains available.
• Dashboards: The Detection & Response and Data Quality dashboards support CPS.
• Intelligence: Threat intelligence indicator searches support CPS.

The following features remain scoped to the origin project:

• Alerts: The Alerts page does not display remote alerts from linked projects.
• Explore page: Host, network, and user exploration searches are scoped to the origin project only.
• Entity store: Entity risk scoring and entity profiles do not include data from linked projects.
• Attack Discovery: AI-generated attack discoveries are based on alerts from the origin project only.
• Overview: The Security Overview page reflects data from the origin project only.
• Defend and Osquery: Elastic Defend and Osquery are scoped to the origin project only. Defend and Osquery are managed through Fleet, meaning their configuration is tied to a single project. Endpoint artifacts, policies, response actions, and Osquery saved queries and packs are managed per project and are not shared across linked projects.

• Cross-project search overview
• Project routing
• How search works in CPS
• Configure cross-project search access and scope
• ES|QL in Kibana
• Query across Serverless projects with ES|QL