Building a Power BI Mobile Layout Step by Step - From Blank Phone Canvas to Published Report
Here's a scene I've watched play out at more than one Australian business. A regional sales manager is standing in a car park between client visits, opens the Power BI app on their phone, and gets a tiny version of a 16:9 report designed for a 27-inch monitor. They pinch, they zoom, they give up, and they ring someone in the office to read the numbers out. The report exists. The data's right. It just isn't usable where the person actually is.
The fix for that is the mobile layout, and it's one of the cheaper wins in Power BI. You don't rebuild anything. You lay out a phone-shaped version of a page that's already there, using the visuals you've already built. Done well it takes less than an hour a page.
We've written before about when mobile-optimised reports are worth building and what works on a phone in general. This post is the practical bit in between: actually sitting down in Power BI Desktop and creating the initial layout. It follows Microsoft's guide on creating a mobile-optimised layout, with notes from what we've learned along the way.
Before you open the mobile canvas
Two minutes of thinking saves a lot of dragging.
Pick the page. Mobile layouts are created per page, not per report. A report with eight pages doesn't need eight mobile layouts. Usually one or two pages are what people check on the go, often a summary page and maybe a "my region" or "today" page. Start there.
Then decide what someone on a phone actually needs. My rule of thumb is that if the desktop page has twelve visuals, the mobile version probably wants four to six. You don't have to put every visual on the mobile canvas, and you shouldn't.
Finally, check your visuals are in decent shape on the desktop version. The mobile layout reuses the same visuals, so if a chart has a dodgy title or the wrong sort order, you'll see it in both places.
Opening the mobile layout view
In Power BI Desktop, go to the View ribbon and select Mobile layout. The canvas changes to a phone-shaped grid, and a Page visuals pane appears listing every visual on the current page.
A few things worth knowing straight away:
- Visuals already used on the mobile canvas are marked in the pane, so you can see what's left at a glance.
- Hidden visuals on the desktop page still show up in the list, which is a common source of "why is this here?" confusion.
- The phone canvas scrolls vertically. You're not limited to one screen of content, though you should still keep it short.
To get back to the normal desktop page, use the same View ribbon option. Your work on the mobile canvas is kept per page.
Auto-create as a starting point
Power BI has an auto-create option that generates a mobile layout for you, picking visuals and arranging them based on the desktop page. It's handy, and I'd usually click it first.
My honest view: treat it as a first draft, not a finished layout. It does a reasonable job of getting visuals onto the canvas in a sensible order, but it doesn't know which numbers matter most to your users. On a recent project for a property group, auto-create put a detailed table near the top and the three headline KPI cards below it. Thirty seconds of rearranging fixed it, but if we'd published as-is, every user would have scrolled past a table to get to the numbers they actually check.
If the mobile canvas already has visuals on it, auto-create will want to replace what's there, so use it early, before you've done manual work.
Placing and sizing visuals manually
If you're starting from scratch or tidying up an auto-created layout, the workflow is simple. Drag visuals from the Page visuals pane onto the phone canvas. They snap to the grid. Resize them by dragging the corners and move them around as you'd expect.
Some practical habits we've settled on:
Put the headline numbers at the top. Cards and KPI visuals first. Most people open a mobile report to check one or two figures, and if those are visible without scrolling you've already won.
Go full width for charts. Two charts side by side on a phone are almost always too cramped. Full-width bar and line charts read well. Cards can sit two across if they're short.
Give slicers real space. A slicer that's 20 pixels high is unusable with a thumb. Make it big enough to tap reliably, or think about whether that slicer belongs on mobile at all. Sometimes it's better to have a separate pre-filtered page than a fiddly slicer.
Watch the overlap. Visuals can overlap on the mobile canvas, which is occasionally useful for layering a shape behind cards, but it's mostly a way to create things people tap on by accident.
Keep scrolling modest. One to two screens of content is plenty. If you're past three, you're probably rebuilding the desktop page in a long column, which isn't really helping anyone.
Mobile-only formatting
This is the part a lot of report authors don't realise exists. When you select a visual on the mobile canvas, the Format pane lets you change formatting properties for the mobile version only. The desktop layout is untouched.
That matters because a lot of desktop formatting doesn't translate. Common changes we make:
- Bigger font sizes on titles, data labels and card values
- Turning off legends where the chart is self-explanatory, to save space
- Removing axis titles that eat precious horizontal room
- Shortening visual titles ("Revenue vs Target by Month" becomes "Revenue vs Target")
- Reducing the number of data labels so they don't collide
If you change something on the mobile canvas and want it back the way the desktop version has it, there's a reset option to revert the visual's mobile formatting to match the desktop. Useful when you've been experimenting and lost track.
One caveat: not every formatting property can be overridden for mobile, and a few visual types support fewer options than others. If a setting doesn't show up in the mobile Format pane, it's following the desktop value.
Interactions on mobile
By default, cross-filtering and highlighting between visuals behave the same on the mobile layout as on desktop. You can edit visual interactions separately for mobile though, which is worth doing.
On a phone, a user tapping a bar to cross-filter a chart that's two screens further down won't even notice it happened. Sometimes that's fine. Often it's confusing, especially if they then scroll down and wonder why the numbers look wrong. For mobile pages we tend to simplify interactions: slicers filter everything, and chart-to-chart filtering is limited to visuals that sit close together on screen.
How changes flow between layouts
Understanding this saves frustration later:
- If you change a visual's data or fields on the desktop layout, the mobile version updates too, because it's the same visual.
- Mobile formatting changes stay on mobile.
- If you delete a visual from the desktop page, it disappears from the mobile layout as well.
- Adding a new visual to the desktop page doesn't add it to mobile automatically. It just appears in the Page visuals pane, ready to drag on.
That last one bites people. Someone adds a new KPI to the desktop page, publishes, and the mobile users never see it. If mobile matters for a report, make "check the mobile layout" part of your release checklist.
Publishing and testing on a real phone
Once you publish, the Power BI mobile app shows the mobile-optimised layout when someone opens that page on a phone in portrait mode. Turn the phone sideways and they'll get the regular desktop layout. Pages without a mobile layout just show the desktop version scaled down.
Please test on an actual phone. The Desktop preview is close, but it's not the same as holding the device. Things we've only caught on real phones include slicers too small for an average thumb, card values truncating with an ellipsis on smaller screens, and dark-mode colour combinations that looked fine in Desktop and became unreadable on an iPhone in dark mode.
I'd also suggest getting one or two real users to try it in their actual context. On a construction project, we learned that site supervisors were reading the report in bright sunlight with gloves on. Pale grey text and small tap targets were never going to work. You don't find that out from a desk in the CBD.
What's still a bit rough
The mobile layout feature is solid but not perfect.
It's per page, so a report with several pages that all need mobile versions is repetitive work. Some custom visuals don't behave well at phone widths regardless of how you size them. Bookmarks and complex navigation built for desktop don't always translate, and you may end up building a simpler navigation path for mobile users. And there's no easy way to see, across a large tenant, which reports have mobile layouts and which don't, so it relies on report authors remembering.
None of that is a reason not to do it. It's a reason to be selective about which pages get the treatment.
Our recommendation
For most organisations, pick the three or four reports people genuinely check away from their desks, and build mobile layouts for the key pages of those. That's usually a day's work in total and it changes how often executives and field staff actually look at their numbers.
If you're working through a broader Power BI rollout and want help deciding where mobile fits, our Power BI consultants do this kind of work regularly. And if you find your users need more than a report on their phone, such as capturing data, approvals or offline access, that's when a proper mobile app or a Power Apps solution starts making more sense than squeezing more into a report page.
For the full click-by-click reference, Microsoft's guide on creating a mobile-optimised layout is the place to go.