The left hand navigation needs to be updated in 2 of the 3 "types" of navigation that exist today (see more about these 3 types of navigation, what each one looks like today, and how each is "controlled" in the "Context: the way nav looks today" section below the AC).
Acceptance Criteria
📍AC 1: Change existing navigation hierarchies for stateful cloud and serverless
Stateful Kibana, On-Premise
No changes required.
Stateful Kibana, Cloud
The new stateful cloud menu hierarchy and design can be found in these Figma frames. The top-level menu and each sub-menu have all been screenshot and added to the table below for convenience.
see this comment about the current source of truth...
| Top |
Applications |
Infrastructure |
Machine learning |
Other tools |
Management |
 |
 |
 |
 |
 |
 |
Note: to put your local Kibana in "stateful cloud" mode, you need to add the following configuration keys to your kibana.yml file (the values are not relevant, only that there is SOME value there):
xpack.cloud.id: "fake_cloud_id:24h124h11249u31r4"
xpack.cloud.base_url: "https://cloud.elastic.co"
The “switch on new navigation” will still be an opt-in (per space) in stateful, in 8.16 (as is the current behaviour)
- You opt in via
Stack Management > Spaces > Navigation > Set solution view
- Change from empty/classic, to
Observability

Serverless Kibana
The new serverless menu hierarchy and design can be found in these Figma frames. The top-level menu and each sub-menu have all been screenshot and added to the table below for convenience.
see this comment about the current source of truth...
| Top |
Applications |
Infrastructure |
Machine learning |
Project management |
 |
 |
 |
 |
 |
📍AC 2: Change sub-navs from "accordion" style opening to a "slide out" method instead
Currently, the existing nav in both Kibana Stateful Cloud and Kibana Serverless open sub-navigation sections using the "accordion" pattern.
|
|
| Accordions Closed |
 |
| Accordions Open |
 |
For these menu items to open their sub-navigation menus in a "tray", sliding out to the right, the "panelOpener" pattern must be used instead. This is how the "Stack Management" navigation item works today (notice the different icon used, the four small squares instead of the caret).

As it exists today, when "panelOpener" is chosen for this menu item, you are required to provide a valid URL for the "link" property. As you can see in the "Stack Management" example above, there is a separation between the label, "Stack Management", and the icon to its right. Clicking on the label opens the URL assigned to the "link" property, whereas clicking on the icon opens the sub-nav as a tray to the right. This is NOT what we want for our new menus.
Instead, we want to update this "panelOpener" option so that it no longer requires the "link" property, and instead behaves slightly differently when no "link" prop is passed.
- The icon should change from the four small squares to the right-facing caret
- The sub-nav menu should slide out to the right whenever the label OR the icon are clicked
Notes about this AC

For simplicity, this is NOT necessary at this time—it's ok if the label and icon are separate link targets as long as they both open the menu's sub-nav.
📍AC3: Add appropriate tests
Particularly if we change how the UI components work for the accordion vs "panelOpener" mechanics (mostly in the packages and files specified in AC2 notes), we should look to add some tests for the changes we introduce. Beyond that, we should also consider adding wholly new functional tests for the new side navigation in stateful cloud (see this linked sub-issue for details)
📍AC4: Confirm breadcrumbs work as expected
We need to check to see if breadcrumbs have been broken once these navigation changes are in place. If we discover issues with breadcrumbs, fix if possible or at the very least, please log a follow up ticket so we can address separately, depending on the size of this PR and the complexity of the breadcrumbs problem(s).
It's not necessary to visit every page listed in the navigation hierarchy and confirm each breadcrumb, the main problem we expect to find, if any, is that the parts of the navigation tree which don't represent actual pages in the UI (e.g. the top level "Applications" link is only a link to open a sub-nav and no longer corresponds to any real page in the UI) may have rendering issues in the breadcrumb.
Other information about breadcrumb logic can be found in this Synthetics PR, and @justinkambic may be able to provide more details if needed.
Context: The way navigation looks today
There are currently at least three different configurations of the left-hand primary navigation in Kibana.
| Type |
Controlled by? |
Existing Screenshot |
| Stateful Kibana, On-Premise |
Observability plugins control this navigation using the observability shared plugin's navigation.registerSections method which then passes those registered sections to the global observability <PageTemplate> component used to wrap all observability pages |
 |
| Stateful Kibana, Cloud (with Solution View) |
As of (recently, not sure what version), cloud instances provide a new space-level setting called "Navigation > Set solution view" that allows the user to choose "Observability", "Security", or "Classic" options. This provides these users with an "opt-in" choice to use this new navigation. 
If "Observability" is selected, the left navigation will be driven by the file found at observability_solution/observability/public/navigation_tree.ts. Note: to put your local Kibana in cloud mode and enable this setting your space settings, you'll need to add fake values for two config keys into your kibana.yml file. Those are 'xpack.cloud.id' and 'xpack.cloud.base_url' and they can each be any random string. |
 |
| Serverless Kibana |
Serverless projects that use the "observability" project type have a left navigation that is controlled by the serverless_observability/public/navigation_tree.ts file. |
 |
The left hand navigation needs to be updated in 2 of the 3 "types" of navigation that exist today (see more about these 3 types of navigation, what each one looks like today, and how each is "controlled" in the "Context: the way nav looks today" section below the AC).
Acceptance Criteria
📍AC 1: Change existing navigation hierarchies for stateful cloud and serverless
Stateful Kibana, On-Premise
No changes required.
Stateful Kibana, Cloud
The new stateful cloud menu hierarchy and design can be found in these Figma frames. The top-level menu and each sub-menu have all been screenshot and added to the table below for convenience.
see this comment about the current source of truth...
Note: to put your local Kibana in "stateful cloud" mode, you need to add the following configuration keys to your
kibana.ymlfile (the values are not relevant, only that there is SOME value there):The “switch on new navigation” will still be an opt-in (per space) in stateful, in 8.16 (as is the current behaviour)
Stack Management > Spaces > Navigation > Set solution viewObservabilityServerless Kibana
The new serverless menu hierarchy and design can be found in these Figma frames. The top-level menu and each sub-menu have all been screenshot and added to the table below for convenience.
see this comment about the current source of truth...
📍AC 2: Change sub-navs from "accordion" style opening to a "slide out" method instead
Currently, the existing nav in both Kibana Stateful Cloud and Kibana Serverless open sub-navigation sections using the "accordion" pattern.
For these menu items to open their sub-navigation menus in a "tray", sliding out to the right, the "panelOpener" pattern must be used instead. This is how the "Stack Management" navigation item works today (notice the different icon used, the four small squares instead of the caret).
As it exists today, when "panelOpener" is chosen for this menu item, you are required to provide a valid URL for the "link" property. As you can see in the "Stack Management" example above, there is a separation between the label, "Stack Management", and the icon to its right. Clicking on the label opens the URL assigned to the "link" property, whereas clicking on the icon opens the sub-nav as a tray to the right. This is NOT what we want for our new menus.
Instead, we want to update this "panelOpener" option so that it no longer requires the "link" property, and instead behaves slightly differently when no "link" prop is passed.
Notes about this AC
The "link" prop requirement for the "panelOpener" option is governed by the
validateNodePropsmethod in the packages/core/chrome/chrome-browser-internal/src/project-navigation/utils.ts fileThe actual rendering of these left navigation sections and the slide out "panel" are in the packages/chrome/navigation/src/ui/components folder.
The designs from Figma show the menu button as a single link target, highlighted as a single rectangle.
For simplicity, this is NOT necessary at this time—it's ok if the label and icon are separate link targets as long as they both open the menu's sub-nav.
📍AC3: Add appropriate tests
Particularly if we change how the UI components work for the accordion vs "panelOpener" mechanics (mostly in the packages and files specified in AC2 notes), we should look to add some tests for the changes we introduce. Beyond that, we should also consider adding wholly new functional tests for the new side navigation in stateful cloud (see this linked sub-issue for details)
📍AC4: Confirm breadcrumbs work as expected
We need to check to see if breadcrumbs have been broken once these navigation changes are in place. If we discover issues with breadcrumbs, fix if possible or at the very least, please log a follow up ticket so we can address separately, depending on the size of this PR and the complexity of the breadcrumbs problem(s).
It's not necessary to visit every page listed in the navigation hierarchy and confirm each breadcrumb, the main problem we expect to find, if any, is that the parts of the navigation tree which don't represent actual pages in the UI (e.g. the top level "Applications" link is only a link to open a sub-nav and no longer corresponds to any real page in the UI) may have rendering issues in the breadcrumb.
Other information about breadcrumb logic can be found in this Synthetics PR, and @justinkambic may be able to provide more details if needed.
Context: The way navigation looks today
There are currently at least three different configurations of the left-hand primary navigation in Kibana.
navigation.registerSectionsmethod which then passes those registered sections to the global observability<PageTemplate>component used to wrap all observability pagesAs of (recently, not sure what version), cloud instances provide a new space-level setting called "Navigation > Set solution view" that allows the user to choose "Observability", "Security", or "Classic" options. This provides these users with an "opt-in" choice to use this new navigation.
If "Observability" is selected, the left navigation will be driven by the file found at observability_solution/observability/public/navigation_tree.ts.
Note: to put your local Kibana in cloud mode and enable this setting your space settings, you'll need to add fake values for two config keys into your kibana.yml file. Those are 'xpack.cloud.id' and 'xpack.cloud.base_url' and they can each be any random string.