Local Navigation helps users move within a specific product area or workflow. It complements Global Navigation by being context-specific, task-oriented, and adaptive to the current dashboard or process step. It supports orientation in flows, navigation between related sections, and forward/back movement without losing context.
Local Navigation is dynamic and flexible and doesn’t need to exist everywhere in Edge.One. Simple applications may not require it. It becomes relevant when dashboards have dependencies (for example, favorites, nodes, or multi-dashboard processes). Because it is limited to the current dashboard context, it can vary between dashboards and should match the local structure and needs of the area.
Local Navigation is composed of reusable navigation surfaces that appear within a dashboard. The set of surfaces depends on the complexity of the area: some dashboards only need lightweight navigation, while others benefit from a persistent structure such as a Navigation Boardlet. Together, these surfaces should support both vertical navigation (drilldowns) and horizontal navigation (step-based flows).
The Navigation Boardlet is an expandable and collapsible navigation element. It sits on the far left of the dashboard and spans from top to bottom. It provides links and tools for navigating within the current product area, typically presented as a list or a tree.
Navigation items are usually grouped to improve scanning and to reflect the information architecture. Each group should have a clear heading and a distinct icon so users can quickly understand what belongs together.
The boardlet can include dynamic elements that update based on context. For example, counters to the right of links can indicate the number of items in a library behind that link. When a boardlet contains many items, it should support independent scrolling so the dashboard content remains usable.
By combining hierarchical structures with direct links, the Navigation Boardlet supports both horizontal navigation (moving between peer areas or steps) and vertical navigation (drilling down into deeper levels of detail).
Click here for more information on the Navigation Boardlet.
Breadcrumbs show users their current location relative to the information architecture. They enable users to quickly move up to a parent level or return to a previous step.
Breadcrumbs are always located in the left part of the header. All page items in the breadcrumb component are interactive and link to the corresponding pages. The go-back icon moves back one step at a time within the page structure.
They support vertical navigation inside drilldowns and adjust based on the user’s current position in the structure.
Navigation actions are elements placed inside the dashboard content. They allow users to continue a task directly from where they are working, instead of relying only on side navigation structures. These actions are most useful when navigation is a consequence of an interaction, such as opening details, progressing through steps, or confirming a decision.
Common placements include:
Table navigation is commonly provided as row actions, placed in the last column. It typically routes users to a drilldown page (for example, a details view), representing vertical navigation to the next layer in the breadcrumb structure. The destination screen should provide a clear “Back” option to return to the prior context.
Navigation can happen through buttons or links placed within the dashboard content, often to support process flows. They are commonly used for horizontal navigation through a sequence of steps. Typical examples include “Next” and “Back.” These actions usually appear in toolbars, footer bars, or at the bottom of the content and should be used sparingly to avoid clutter and conflicting navigation paths.
For more information, please go to the Wizard pattern.
Dialog navigation is usually implemented through footer bar actions. It typically includes two directions:
Depending on the action performed, dialog-based navigation can represent vertical navigation (to a deeper level) or horizontal navigation (to the next step in a flow).
Local Navigation should reflect the user’s current dashboard, task, and information architecture. Avoid reusing navigation structures that don’t match the local workflow, and keep the available options relevant to what users can do from this area.
While Local Navigation can vary between dashboards, patterns should remain consistent within the same application area. Use the same placement, interaction model, and naming conventions so users can predict how navigation works.
Use Local Navigation sparingly and avoid duplicating Global Navigation. If users need to jump between dashboards or products, that belongs in Global Navigation—not local structures.
Prefer clear groupings over long flat lists, and avoid deep trees. If a structure becomes hard to scan, add grouping, shorten labels, or introduce search and shortcuts instead of adding more nesting.
Use a Navigation Boardlet for persistent cross-section navigation within an area. Use breadcrumbs primarily for orientation and moving up a hierarchy. Use in-content navigation actions for step-based flows or drilldowns where users need to act and then move forward.
Do not navigate users directly into the middle of a process or conditional content. Local navigation should route to process entry points or overviews. Step-to-step movement belongs inside the process UI (for example, Next/Back actions).
Drilldown destinations should include a reliable “Back” option or a clear breadcrumb path. Dialog-based navigation should always include an explicit way to return to the current page without progressing.
Use user-facing language, keep titles concise, and match labels with page titles. Avoid internal jargon, and ensure similar destinations have distinguishable names.