How to create a Power BI landing page for multiple reports

Before choosing a tool, list the destinations people need. Record each report's business name, intended audience, owner, and approved viewing link. Keep the technical workspace name in your maintenance inventory; employees should not have to understand it to find their work.

Here is an illustrative structure for three teams. These are example names, not a customer deployment:

Keep the first level short. Group destinations by the decisions people make, and add a sentence explaining what each report answers. Use deeper folders only when they make the next choice clearer. A second enormous list inside a folder does not solve the original problem.

If a native app already gives your audience a clear experience, start there. A portal becomes useful when maintaining and navigating the collection is a recurring burden, especially across separate reporting areas.

Microsoft offers workspace apps and newer Org Apps. They are different app types, so first confirm which one your team uses. Org Apps support an overview page, navigation sections, links, and audiences. Included content comes from the app's workspace; adding a link to another destination is different from including that item.

For an Org App, the basic setup is:

1. In a supported workspace, choose New → Org app and name it.
2. Use Add content to select the supported items you want to include.
3. Add an Overview and navigation Sections. Arrange the first item as the starting experience.
4. Add links where needed, configure audiences and access, then save and share the app.

App creation and access changes require the appropriate workspace permissions. Consult Microsoft's Org Apps guide for current prerequisites and audience behavior.

For the example above, department-specific apps may be sufficient. Before introducing another tool, ask users to find a report outside their usual department. That exercise will reveal whether the app structure matches how people actually work.

A small report can act as a visual directory. Each button opens a different report or app using its viewing URL. This can be a useful starting point when the destination list is short and changes infrequently.

1. Collect the right links. Open each destination as its intended audience would. Use the app-context link if users receive access through that app.
2. Create the starting page. In Power BI Desktop, add a page with a clear heading and the business categories from your report map.
3. Add a button for each destination. Choose Insert → Buttons. Give each button a descriptive label, such as Monthly revenue.
4. Connect the destination. In the button's formatting pane, enable Action, select Web URL, and enter the destination link. Test it with Ctrl-click while editing.
5. Publish and verify. Share the landing report through your normal governed process, and check every link with a representative viewer account.

Use Web URL for a separate report. The Page navigation action moves between pages within the same report. Microsoft explains these actions in its button configuration guide.

The tradeoff is upkeep: moved or replaced reports need updated links, and the directory layout needs attention as the list grows. Give users an obvious way to return to the starting page after following a link. For a larger collection, a searchable directory or persistent navigation may be more useful than another row of buttons.

LumioBI is another approach: administrators curate the navigation, and employees use a browser extension to keep that portal available while working in native Power BI. It is not a standalone embedded-report website. Plan the extension installation with your organization before rollout.

To translate the example report map into a portal:

1. Create the structure. In LumioBI's Navigation editor, add Finance, Sales, and Operations folders, then their subfolders and report links.
2. Make the menu relevant. Configure group visibility for the intended audience and add useful resources beside reports, such as metric definitions or a support link.
3. Review and publish the navigation. Check the draft, then publish the portal configuration when it is ready for users.
4. Walk through the employee experience. With the extension installed and the user approved for the portal, open Power BI, find Monthly performance in the menu or search, and save it as a favorite.

The benefit is continuity: employees can move between the reports you curate without repeatedly returning to a separate directory. Explore layered navigation and portal search to see the experience in more detail.

Give someone outside the BI team three tasks: find a familiar report, find one from another business area, and return to the starting point. Watch where they hesitate. That is more useful feedback than asking whether the page looks good.

• Every report name describes a business question or task.
• Each link opens the intended report for an ordinary viewer, not only an administrator.
• People without permission remain unable to access restricted reports, even with a direct link.
• Users know how to return or switch to another report.
• A named owner will review broken links, retired content, and audience changes.
• The experience works in the browsers and devices your audience actually uses.

After launch, track successful report discovery and repeat use. Ask which links people still request by email. Use that feedback to simplify the structure before adding more destinations.