Power BI Bookmarks - How to Use Them Without Making a Mess
I've been called into a lot of Power BI cleanup jobs over the last few years. The pattern is depressingly familiar. A new BI analyst joins the team, watches a YouTube tutorial about bookmarks, and a month later the company has a 40-page report with 200 hidden objects, a dozen overlapping bookmark groups, and a navigation pane that nobody quite remembers how to update. The original author has moved on. The replacement opens the file, takes one look at the Selection pane, and books a meeting with someone like me.
Bookmarks are genuinely useful. They're also the feature I see misused more than almost any other in Power BI. So this post is part promotion, part warning. If you're new to bookmarks, here's what they do and why I like them. If you've been using them a while, here are the traps I keep seeing.
What a bookmark actually captures
When you create a bookmark, Power BI takes a snapshot of the current state of the page. Slicer values, filter pane state, drill-down position, sort order, spotlight settings, and the visibility of every object in the Selection pane. You can choose which of those properties to include or exclude when you save the bookmark, which matters more than people realise.
By default, a new bookmark saves everything. That's almost never what you want. If you save "everything" for ten bookmarks on a page, you've now hard-coded ten copies of every slicer value across the page, and any change to the slicer logic later means going back and updating ten bookmarks. Always think about what the bookmark is meant to do, and turn off the properties it doesn't need to control. If a bookmark is only meant to swap two visuals on the page, untick Data and Current page in the bookmark options. Just leave Display checked. Future-you will be grateful.
The two patterns that actually pay off
After years of seeing what works, I keep coming back to two patterns. Most of the bookmarks I build in client work fall into one or the other.
Custom navigation overlays. Power BI's built-in page navigation is fine, but bookmarks let you build a slide-out menu, a tab strip, or a "click this card to drill into detail" pattern that feels much more like a polished app. The trick is to use a single navigator object backed by bookmarks rather than a page selector. This is how almost every executive dashboard we ship looks now. The user sees a clean nav strip across the top. The actual machinery underneath is a bunch of shapes wired to bookmarks.
Show/hide layers for what-if and comparison views. A bookmark can swap the visible layer of a page. You can have a "high level" view and a "drill into product detail" view living on the same page, and a button that toggles between them. This is much faster than building two pages and navigating the user between them. It also keeps slicer state intact, which a page navigation always breaks unless you sync slicers across pages.
Those two patterns cover maybe 80 percent of bookmark use in the reports we build. The rest is one-offs, like a bookmark that resets all filters back to a default state. Which, by the way, is something every report should have. Add a "Reset" button to the top of every report you ship. Users will accidentally filter themselves into a corner. Give them a way out.
Where bookmarks get out of hand
The Selection pane is the most under-used tool in Power BI Desktop, and it's the first place a bookmark mess shows up. Every shape, image, and visual on the page sits in the Selection pane in a flat list with auto-generated names like "Rectangle 47" and "Text box 12". When you have 60 objects on a page and you're trying to figure out which ones belong to which bookmark, it becomes a guessing game.
The fix is simple but boring. Name every object in the Selection pane. Group related objects so they show up nested. When you create a bookmark, do it deliberately, with the Selection pane in front of you so you can see exactly which objects are visible. If you're building a bookmark that hides 15 things and shows 3, group those 15 and 3 first. Then you only need to toggle the visibility of two groups in the Selection pane, not 18 individual items.
I had a project last year where a client wanted us to "just add one more bookmark" to a finance report. It took two days to untangle what was on the page well enough to add the new state safely. Two days. For one bookmark. Don't let your reports get to this place.
The other trap is the "everything bookmark" anti-pattern. Someone wants the report to start in a default state, so they make a bookmark that captures every slicer and every visibility setting. Then a stakeholder asks for a new measure, you add a slicer for it, and now the default bookmark is wrong because it doesn't know about the new slicer. New bookmarks born after old ones can drift in subtle ways. Bookmarks should be small and focused. If you find yourself needing a single bookmark to do five things, you probably want five small ones grouped together.
Sharing insights with bookmarks
The original promise of bookmarks was that an analyst could capture a specific finding (this filter, that drill, this highlighted bar) and share it as a frozen view. That use case still works and I think it's under-loved. If you find something interesting in a report and you want to send a colleague the exact state you're looking at, hit View > Bookmarks > Add and tick Personal bookmark. They get a private bookmark in the service, separate from the report bookmarks the report author shipped. It's a way to say "look at this" without screenshots.
The catch is that you need to actually train your users to do this. Most users don't know personal bookmarks exist. We bake this into our Power BI training for analyst teams, because it changes the way people talk about findings in meetings. Instead of "I saw something weird in the East region last quarter, hang on while I find it again", they have a bookmark labelled "East region weirdness Q3" and pull it up in two clicks.
For larger organisations rolling Power BI out across hundreds of users, this kind of small workflow detail makes the difference between adoption and abandonment. We see it constantly in the enterprise BI work we do.
A word on bookmarks in the Power BI service vs Desktop
There's a small but important difference between bookmarks as the report author and bookmarks as a viewer. Authors create report bookmarks in Power BI Desktop, and those bookmarks ship with the report. Anyone who views the report in the service can see them. Viewers can also create their own personal bookmarks in the service. These live with the viewer's account, not the report.
A viewer can also share a personal bookmark via a link. Click the bookmark, click Share, and you get a URL that opens the report in that exact bookmarked state. This is the killer feature for collaboration. Most people don't know it exists. Tell them.
One catch: personal bookmarks don't survive a republished report if the page or the slicer layout changes significantly. The bookmark tries its best to apply the saved filter state, but if the slicer it's pointing to has moved or been renamed, it falls back gracefully and loses that filter. Worth knowing so you don't waste time chasing a "bookmark broke" ticket.
When not to use bookmarks at all
Sometimes the right answer is no bookmark. If you're doing a measure swap, field parameters do the same job with less ceremony. If you're showing and hiding entire pages, use page navigation buttons. If you're doing a true drill-through, use Power BI's drill-through feature, which is more discoverable to end users than a hidden bookmark behind a button.
The general rule I use: if you can express the same behaviour with a built-in feature, use the built-in feature. Bookmarks are a glue layer. Save them for things that can't be done another way.
The other place I avoid bookmarks is in reports that are going to be embedded in another application. The embedded API has its own state management, and bookmarks can fight with it. If you're building a custom AI-powered application that embeds Power BI visuals, like the kind of thing we build under our custom AI work, you usually want to drive state through your application, not through bookmarks living inside the report.
Practical advice if you're starting today
Build small. One bookmark per behaviour. Name everything in the Selection pane. Untick the properties you don't need each bookmark to control. Train your users on personal bookmarks. Add a Reset bookmark to every report. Use field parameters or page navigation when they fit. Audit your bookmark list every few months and delete the ones nobody clicks.
If you do those things, bookmarks will earn their keep. If you don't, you'll end up with a report nobody wants to maintain, including you.
For more detail on the mechanics of how bookmarks work, the Microsoft documentation is solid - have a read of the Power BI Desktop bookmarks page for a full walkthrough of the options.
If you've inherited a Power BI estate that's gone the wrong way on bookmarks (or just sprawled in general), have a look at how we approach Power BI consulting and feel free to get in touch. The first thing we usually do is open the Selection pane and start tidying up. It's not glamorous, but it's where most of the value lives.