Power BI Buttons - The Small UX Lever That Makes Reports Feel Designed

Buttons in Power BI are one of those things every report builder eventually needs and most never quite master. They look simple. You drop one on the canvas, set an action, and you're done. Except a report that uses buttons well feels like an application. A report that uses them badly feels like a wall of clip art with hyperlinks.

I want to talk through how we actually use buttons in client reports, what's worth the effort, and where we've made mistakes. Most of the advice in the Microsoft docs is correct but a bit dry. The real question is when to bother and when to leave it alone.

What buttons can actually do now

The set of actions a Power BI button can take has grown a fair bit over the last few years. The basic ones have always been there: navigate to another page, open a URL, trigger a bookmark. The newer ones are where the interesting work happens.

You can have a button toggle a slicer state, change a measure being shown via field parameters, kick off a Power Automate flow, or fire a Q&A query. You can have it set a drillthrough filter. You can have a button perform a write-back if you've wired up the right capabilities behind it. The button is no longer just navigation furniture. It's an actual control surface for the report.

The styling has also caught up. You can set the icon, the fill, the border, the shadow, the hover state, the pressed state, the disabled state. You can use a custom shape from your own design system. You can make it look like a button on a website rather than a button from PowerPoint 2007. Most teams haven't caught up to what's possible because the defaults still look like PowerPoint 2007.

The practical patterns we use

Here are the ones we keep reaching for.

Navigation buttons that look like a nav bar. Drop four or five buttons across the top or down the side of the report, each navigating to a different page. Style them so the active page's button looks different. Suddenly the report has an actual navigation pattern. Users stop using the page tabs at the bottom, which is good because the page tabs at the bottom are ugly and small. The page tabs should be hidden in any report you'd describe as production-ready.

Reset filter buttons. A button wired to a bookmark that captures the "default" state of the page. Click it, all filters reset. This is the single highest-value button you can add to a report. Users get into a tangled filter state, and rather than refreshing the browser they click the button. We add this to almost every report we build. Costs five minutes. Pays back every single time.

Show/hide detail panels. A button that triggers a bookmark, swapping between a summary view and a detail view. This lets you fit two layouts into one page. Particularly useful when the exec team wants a "headline" view and the analyst team wants the underlying breakdown. Same data, same page, two presentations.

Action buttons that kick off Power Automate. This is the underused one. A button that triggers a flow can do anything from "email this report as a PDF to the recipients on this row" to "create a follow-up task in our project system for the customer that's currently filtered". For sales reporting and operations dashboards, this is the bit that turns the report from a viewer into a tool people actually use to take action.

Field parameter selectors. Buttons that change which measure or dimension a chart is showing, layered on top of the field parameters feature. A row of buttons that read "Revenue / Margin / Units" sitting above a chart is a cleaner UX than a slicer. Three clicks become one. Field parameters are the underlying engine. Buttons are the friendly face.

This is where the small details accumulate. We see the same patterns work across the Power BI reporting we build for Australian clients.

The styling, briefly

A few things we've learned about making buttons look like they belong on the page.

Don't use the default fill colour. It's a slightly off blue that doesn't match anything else in the report. Pick a colour from your client's brand palette. Apply it consistently to every button. The instant a button uses a custom fill, the report starts to look intentional.

Use rounded corners. The default square corners look like wireframes. A radius of 4 or 6 pixels is enough to soften them. The "rounded rectangle" shape rather than the "rectangle" shape has this built in.

Set a hover state. This is the single biggest thing that separates a Power BI button from a button on a website. The hover state should change the fill colour, change the text colour, or shift the shadow. Anything to give feedback that the button is interactive. Users learn to trust the button because it responds.

Set a disabled state if the button is conditional. A button that only does something when a particular filter is active should look greyed out the rest of the time. You wire this up using conditional formatting on the button's "Disabled" state. A small detail that makes the report feel polished.

Don't use the default Microsoft icons. They look like Office 2013. If you need icons, use a clean icon library like Fluent or Phosphor and upload the SVGs as custom icons. Or skip the icons entirely. Text-only buttons can look great.

Where buttons go wrong

A few things we see clients do that turn buttons from a feature into a problem.

Too many buttons on one page. If your report has eight buttons across the top, three on each side, and four in the middle, the report has stopped being a report and become a remote control. The user spends more time figuring out what each button does than actually looking at the data. Aim for the smallest number of buttons that still give the user the control they need.

Buttons that don't look like buttons. A blob with text on it that you have to know is clickable is not a button, it's a guessing game. If something is interactive, it should look interactive. Use a fill, a border, a shadow, something. The "transparent button over an icon" trick is fine for tiny actions but is overused.

Buttons that take an action with no feedback. A button that triggers a Power Automate flow and then sits there silently is unnerving. Users will click it three or four times in a row. Wire up a confirmation: a tooltip, a status text element that changes, anything. The button needs to feel like it did something.

Bookmark hell. A page with 14 bookmarks and 14 buttons, each toggling a different combination of visuals, is a maintenance disaster. If your bookmark count starts climbing past five or six, stop and ask whether you should be using field parameters, sync slicers, or a drillthrough instead.

The things still missing

Honest assessment. Buttons in Power BI are good, not great, and a few capabilities we'd like aren't there yet.

There's no native way to write a value back to a database when a button is clicked, without going through Power Apps or Power Automate. The integrations work but they're indirect. If you want a "Save" button that updates a row in SQL, you're stitching together two or three services.

The conditional formatting on button states is still clunkier than the equivalent in visuals. You can do most things but the experience is fiddly. Sometimes the right answer is to build the button as a card visual with a custom action, just so you get the full formatting power. This is silly. It works.

The button click event doesn't expose context cleanly to flows. If you want to know which row was selected when the button was clicked, you have to set up data alerts or pass context via filters, neither of which is ideal. We've found workarounds but it's an area where the experience falls short of, say, the equivalent in a custom React dashboard.

This is the kind of thing we factor into strategic decisions about Power BI versus a custom build. For most clients, Power BI is the right call because the trade-offs favour the cost and speed. But there are cases where the limitations stack up and a custom UI ends up being the better answer.

Small thing, large effect

The reason we keep talking about buttons is that they're the single biggest lever for making a report feel designed rather than dumped together. A report with thoughtful navigation buttons, a reset button, and a few field parameter switchers is a different product from a report with three slicers and seven pages of small multiples. Same data. Same model. Different experience.

If you're refreshing a Power BI report and looking for the highest-impact change you can make in an afternoon, look at the buttons. Add the reset button. Style the navigation. Replace one slicer with a row of buttons. Then watch how the users react.

If you'd like a hand turning a report estate from "spreadsheets on the wall" into something users actually like opening, we can help out. And the original Microsoft reference is here if you want the full feature list: Customize buttons in Power BI.