Power BI Page And Bookmark Navigators - The Hidden Trick For Cleaner Reports

If you've ever built a Power BI report with five or six pages and tried to put navigation buttons across the top, you'll have run into the same annoying problem I have. Every time you add a new page, you've got to go back to every other page, add a button for the new page, position it, format it, set the action, and make sure it doesn't break the layout. By the time you're on report version 14, you've spent an hour and a half on button maintenance and the client has changed the page names again.

Page and bookmark navigators fix that. They're a single visual that auto-generates buttons for every page in the report, or every bookmark in a group. Add a new page, the navigator picks it up. Rename a page, the button updates. It's the kind of feature that, once you start using it, you can't quite believe you were doing things the other way before.

I want to walk through what they are, how we use them on client reports, and the small gotchas that you don't read about in the docs.

What they actually do

The page navigator is a visual you drop on the page. It looks at the report's page collection and renders a button for each visible page. The current page's button gets highlighted differently from the others. Click a button, you navigate to that page. Add a new page to the report, the navigator adds a button. Reorder pages, the navigator reorders the buttons. It's a single visual that maintains your nav for you.

The bookmark navigator does the same thing but for bookmarks. You create a bookmark group, drop the navigator on the page, and it generates buttons for each bookmark in the group. Useful for switching between report states, like "by region" versus "by product" views of the same data.

Both are documented properly here: Power BI page and bookmark navigators documentation.

Why this matters more than it sounds

The thing nobody mentions about Power BI report development is how much time gets eaten by the small maintenance stuff. Button positioning, page renames, bookmark management. Each individual task is small. Over a project, they add up. We've measured this on internal builds and on average, navigation maintenance is somewhere between 5 and 10 percent of total report build time. That's not nothing.

The page navigator drops that to nearly zero. You build it once, you forget about it, the report maintains itself.

The other benefit is consistency. When every developer on the team is hand-building navigation buttons, you get subtle differences across reports. One report has rounded buttons, another has square ones. One uses 14pt text, another 12pt. None of it matters individually but it makes the report portfolio look inconsistent. The navigator gives you one standard look that's easy to enforce.

Where we use them

Honestly, page navigators go on almost every report we build now. There's not much reason not to.

The patterns we see most often:

A top-of-page navigator that lets the user jump between report pages. Standard pattern, looks like a tab strip.

A left-side navigator with vertical buttons. Slightly more space-efficient if you've got a lot of pages.

A bookmark navigator for filtered views of the same page. We did a financial services report last year where the user wanted to switch between "total portfolio," "high-value clients only," and "at-risk clients only" views of the same page. Each view was a bookmark with different slicer states. The bookmark navigator gave us a clean three-button switch at the top of the page without any manual button work.

Combination of both, where the top nav uses a page navigator and the in-page view switcher uses a bookmark navigator. This is our standard pattern for medium-to-large reports now.

The formatting that makes them feel polished

Out of the box the navigators look a bit plain. A few formatting tweaks make a big difference.

Set the selected state styling differently from the unselected state. The default is subtle. Bump up the contrast so the user can clearly see which page they're on. We usually set the selected button to the brand's primary colour with white text, and the unselected buttons to a light grey background with darker text. Simple but it reads cleanly.

Set the hover state too. The default hover is the same as the unselected state, which means there's no feedback when the user mouses over a button. Add a slight darken on hover and the buttons feel more responsive.

Use the icon options if you've got them. The navigator supports an icon next to the page name. For client reports we'll often add small icons for sections like Sales, Operations, Finance. Helps users orient quickly. Don't go mad with icons though, they can make the nav look cluttered.

Set the corner radius on the buttons to match the rest of the report's styling. The default sharp corners can look out of place against modern visual styling.

If you've got more pages than fit horizontally, the navigator will wrap. Decide whether that's what you want. If not, you might want vertical instead, or you might want to group pages into bookmarks and use a bookmark navigator with fewer buttons.

The gotchas worth knowing

A few things to watch for.

The page navigator picks up every visible page in the report. Hide a page if you don't want it in the nav. There's no way to selectively include only certain pages in the navigator without hiding the others. If you want a partial nav, you either hide pages or you fall back to manual buttons. We've had cases where a client wanted a "user-facing" nav and a "back-office" nav. The clean solution is to hide the back-office pages from the navigator and put a small manual button somewhere out of the way for admin access.

The bookmark navigator only works with bookmark groups. If you've got loose bookmarks, you need to group them first. Easy enough, just clunky if you're used to working with ungrouped bookmarks.

The navigator doesn't have great keyboard navigation. Tab order can be unpredictable. If you've got an accessibility requirement and you're being audited on keyboard navigation, do a thorough test. We've had clients in government and healthcare where this came up and we had to do a fair bit of work around it. Microsoft has improved this over the last few releases but it's still not perfect.

The navigator's interaction with theme changes is sometimes weird. If you switch the report theme after building the navigator, the button styling might not update cleanly. You sometimes have to reset the navigator's format settings to pick up the new theme. Minor annoyance but worth knowing.

Bookmark navigator state persistence can be a bit unpredictable when combined with cross-page navigation. If a user clicks a bookmark button, then navigates to a different page, then comes back, the bookmark state might not be where they left it. Test this if your report uses both navigators together.

Where they fall down

There are a couple of patterns where the navigators aren't the right answer.

If your nav needs to depend on user role, the navigator doesn't help much. Both navigators show the same buttons to all users. Role-based nav still needs to be built with conditional visibility on manual buttons. We've done this with bookmark navigators by using RLS to show different bookmark sets, but it's clunky.

If you've got a non-standard navigation pattern - like a wizard that walks users through steps in a specific order - the navigator isn't quite right. The navigator is for free navigation between independent pages or states. For ordered flows, you want Next/Back buttons with specific actions.

If you need a deeply nested navigation hierarchy - a top-level nav and a sub-nav per section - you can do it with two navigators but it gets messy. We sometimes fall back to manual buttons for the sub-nav level. Not the end of the world but not ideal.

How this fits into broader report design

Navigation is one of those things that's almost invisible when it's done well and infuriating when it isn't. The page navigator is a small piece of a much bigger conversation about how users actually move around your reports.

When we run a Power BI build, we spend a fair bit of time on the navigation model up front. Where are users coming from? What page do they need first? What's the typical jump-to page after that? Get the structure right at the start and the navigator just exposes the structure clearly. Get the structure wrong and no amount of fancy buttons will fix it.

For larger organisations rolling out a portfolio of reports across a Fabric or Microsoft data platform engagement, we'll usually set up a standard navigation pattern that all reports inherit. Same navigator design, same position, same formatting. Users can switch between reports and the nav feels consistent. That's a small thing that pays dividends in adoption.

If you're early in a Power BI journey, it might be worth thinking through your broader data and AI strategy before diving into report-level navigation patterns. The navigation patterns you settle on for one report tend to become the de facto standard across the organisation. Better to think that through deliberately than have it emerge by accident.

The short version

Page navigators handle report-level navigation automatically. Bookmark navigators handle view-state navigation within a page. Both save you time, both make your reports look more consistent. Spend ten minutes on formatting to make them feel polished. Watch for the role-based-nav and accessibility gotchas. Then forget about button maintenance forever.

If you want help with a Power BI rollout or you're thinking about the broader picture of analytics and AI inside your organisation, have a chat with us. The contact details are on our contact page.

Reference: Power BI page and bookmark navigators, Microsoft Learn.