Mobile-Optimised Power BI Reports - When They're Worth Building and When They Aren't

I was at a client site in western Sydney last year, a distribution business with about 300 staff, and the operations manager pulled out his phone to show me "the dashboard". It was a Power BI report designed for a 27 inch monitor, squeezed onto an iPhone screen. Twelve visuals, each about the size of a postage stamp. He pinched, zoomed, scrolled sideways, tapped the wrong slicer, swore, and eventually just said "it's on there somewhere".

He used that report every morning before he got to the warehouse. It was one of the most-used reports in the company. And nobody had ever thought about how it looked on a phone.

That's the situation mobile-optimised reports are meant to solve. Microsoft's documentation covers the basics in About mobile-optimized reports. Here's my take on how the feature works, where it's good, and where it's still a bit clunky.

What a mobile-optimised report actually is

The key thing to understand is that a mobile-optimised report is not a separate report. It's an extra layout attached to each page of your existing report.

Every Power BI report page has its normal layout, the one you design in Desktop or the service. You can optionally add a mobile layout to any page. When someone opens that page in the Power BI mobile app on a phone, held in portrait, they see the mobile layout. Turn the phone sideways and they get the regular layout back.

If a page doesn't have a mobile layout, phone users just see the regular page shrunk down. That's what my operations manager was dealing with.

Because it's the same report, everything underneath is shared. Same semantic model, same measures, same row-level security, same filters. You're not maintaining two copies of the logic. You're just rearranging which visuals appear and where, for a narrow portrait screen.

That's a good design decision on Microsoft's part, and it's the main reason I'd build mobile layouts rather than separate "mobile reports" that drift out of sync with the desktop version.

How you build one

In Power BI Desktop, go to the View ribbon and select Mobile layout. You can also do it in the service when editing a report. The canvas switches to a phone-shaped grid, and a Page visuals pane appears listing every visual on that page.

You drag visuals from the pane onto the phone canvas and resize them on a grid. You don't have to include every visual. In fact, you shouldn't.

A few things worth knowing:

• Visuals you leave off the mobile layout still exist. If you leave a slicer off the phone canvas, its current selection still filters the page. That's useful (you can pre-filter) and dangerous (users can't see why the numbers look the way they do). More on that below.
• You can format visuals differently for mobile. Changes you make to certain formatting properties in mobile layout view apply only to the mobile version. Bigger fonts on the card, hide the axis title, turn off the legend. The desktop version stays untouched. This is genuinely handy and a lot of people don't realise it exists.
• There's an auto-create option. Power BI can generate a starting mobile layout from your desktop layout. In my experience it's a reasonable first pass for simple pages and a mess for complicated ones. Use it to save drag-and-drop time, then rearrange properly.

Once you publish, users with the Power BI mobile app on iOS or Android get the mobile layout automatically when they open the report in portrait. Nothing extra to configure on their end.

What we've seen work

The best mobile layouts we've built for clients all share one trait: they're much smaller than the desktop page. Not a rearranged version of everything. A deliberately cut-down version.

For the distribution client, we went back to the operations manager and asked a simple question: what do you look at on your phone before 7am? The answer was three things. Yesterday's dispatched orders versus target, any orders flagged as late, and stock-outs on the top 50 SKUs. That's it. The other nine visuals were for his weekly review at a desk.

So the mobile layout had a KPI card for dispatched versus target, a short table of late orders, and a short table of stock-outs. Big fonts. One slicer for warehouse location at the top. He told us a month later that it was the first time he'd used the report on his phone without getting annoyed.

Some patterns that hold up across clients:

Lead with cards. KPI cards and multi-row cards read well on a phone. A headline number at the top of the screen answers the "is everything ok?" question immediately.

Prefer tables to complex charts. A short sorted table is easier to read on a phone than a scatter chart or a heavily stacked column chart. Line charts are fine if they're full width and simple.

Vertical scroll is fine, horizontal is not. People are used to scrolling down on a phone. Design for a long, narrow page rather than trying to fit everything above the fold.

Keep slicers to one or two. Slicers take up a lot of space and they're fiddly to tap. If users need more filtering, they probably need the desktop version.

Think about the person, not the page. Mobile users are usually managers, field staff or executives checking something specific. Field supervisors on construction and mining sites in particular have very specific needs, often a single metric for their own site. Design for that.

What's still rough

I'll be honest about the limitations, because they matter when you're deciding whether to invest time here.

It's per page, and it's manual. If you have a 15 page report, that's 15 mobile layouts to design and maintain. When someone adds a new visual to the desktop page, it doesn't appear in the mobile layout until someone goes and puts it there. On reports that change often, the mobile layout drifts out of date. We've had to add "check mobile layout" to clients' report change checklists to stop this.

Hidden filters confuse people. As I mentioned, a slicer that's on the desktop page but not on the mobile layout still filters the data. If a desktop user sets that slicer and saves the report state, or if there's a default selection, mobile users see filtered numbers with no visible explanation. We've had a sales director convinced the numbers were wrong on his phone because a region slicer he couldn't see was set to NSW. Either include key slicers on the mobile layout or make sure the default state is "all".

Not every visual behaves well. Most core visuals work fine. Some custom visuals from AppSource don't resize gracefully or have touch interaction issues. Test on real devices, not just the Desktop preview. The preview is a decent approximation but it's not the same as a phone in someone's hand.

Tablets are a different story. Mobile layout is for phones in portrait. Tablets generally show the regular layout. If your field staff use iPads, which is common in construction and healthcare, design the desktop layout to be readable at tablet size rather than relying on mobile layout.

Interaction is limited. Drill-through, complex cross-filtering and tooltips are all harder to use on a small touch screen. They technically work, but if your report depends on them, the phone experience will feel cramped regardless of layout.

When I'd bother, and when I wouldn't

Not every report needs a mobile layout. Here's roughly how I'd decide.

Build one if:

• The report is used daily by people who aren't at a desk (operations, field staff, sales reps, executives travelling)
• There's a clear "glance" use case, a small number of numbers someone checks quickly
• You can get usage data showing people are already opening it on mobile. The usage metrics report in the Power BI service will show you platform breakdowns. If 30% of views are from mobile and the experience is bad, that's an easy win

Skip it if:

• The report is an analytical tool for people who sit with it for an hour, like a finance variance analysis
• It's a large multi-page report that changes every sprint, and you won't have time to maintain mobile layouts
• Nobody opens it on a phone. Check first rather than assuming

A middle path that works well: build a single dedicated "mobile summary" page in a report, with a carefully designed mobile layout, and leave the other pages desktop only. Users know that page is the phone-friendly one. Maintenance is limited to one page.

Where this fits in a bigger picture

Mobile layouts are a small feature, but they point at something we spend a lot of time on with clients: whether your reports are designed around how people actually work. A lot of Power BI estates in Australian organisations were built report by report over years, each one designed by whoever was asked, for a big monitor, and rarely revisited.

Increasingly we're also seeing clients ask whether a phone dashboard is even the right answer. For some of the "check three numbers every morning" use cases, a short automated message or a Teams notification with the numbers and a link to the full report is better than asking someone to open an app. We've built a few of these using Power Automate and AI-generated summaries, and the uptake has been better than the dashboards they replaced. That's a conversation for a separate post, but it's worth thinking about before you spend days perfecting mobile layouts.

If you want help working out which of your reports deserve mobile attention, or you'd like someone to rework a report estate that's grown messy over time, our Power BI consultants do this regularly. If you're looking at the broader question of getting the right information to the right people, including AI-driven summaries, have a look at our work on AI for business intelligence.