Model-driven app dashboards give your users live, interactive summaries of Dataverse data without spreadsheets or manual reports. This lesson teaches you how to build charts, assemble system dashboards, and set them as the default app experience — step by step with a real scenario.
Picture this: your sales team has been entering opportunities, contacts, and account data into your model-driven app for three months. The data is there — hundreds of rows, cleanly structured in Dataverse — but every Monday morning, someone pulls an Excel export and manually builds a summary slide to answer the same five questions: How many deals are in each stage? Which reps have the highest pipeline value? What's the close rate this quarter? That's a solved problem, and dashboards are the solution.
Model-driven app dashboards give users a live, interactive summary of Dataverse data without requiring them to leave the app or touch a spreadsheet. They're built from components — charts and lists — that connect directly to your existing views, and they update every time someone opens or refreshes them. When configured thoughtfully, a dashboard becomes the first thing a user sees when they open the app, giving them situational awareness in seconds rather than minutes.
By the end of this lesson, you'll understand the two types of dashboards available in model-driven apps, how to build and configure charts from scratch, how to assemble those charts and view-based lists into a working dashboard, and how to set a dashboard as the default experience for your users.
What you'll learn:
You should have a working model-driven app with at least one table that contains real data — even a dozen rows is enough to see charts render. If you haven't built a model-driven app yet, work through Building Your First Model-Driven App: Site Map, Tables, Forms, and Views first. You should also understand what views are, since dashboard list components pull directly from them — Creating and Customizing Views in Model-Driven Apps: Filters, Sorting, and Editable Grids covers that in depth.
Before you click anything, it's worth being precise about terminology, because "dashboard" means two different things in model-driven apps.
Personal dashboards are created by end users inside the app itself. Any user can click the "New" button on the dashboard area, build a layout with charts and lists, and save it — but only they can see it. Personal dashboards are great for power users who want a custom view of their own work. They can't be managed or deployed by administrators across an organization.
System dashboards are created by makers in Power Apps Studio (or the classic solution explorer) and published as part of the app. When you publish a system dashboard, every user with access to the app can see it. You can also set a system dashboard as the default landing page for the entire app. System dashboards are what you'll configure when building a professional, organization-wide experience.
Note
Users can always switch between dashboards using the dropdown at the top of the dashboard area. If you've set a system dashboard as the default, it appears first, but users aren't locked into it unless you specifically restrict their ability to create personal dashboards through security roles.
In this lesson, we'll focus on system dashboards because they're what actually gets deployed. But almost everything you learn applies equally to personal dashboards — the UI is nearly identical.
Every chart on a model-driven dashboard starts as a chart definition on a specific table. Charts aren't created inside the dashboard editor itself — they're created at the table level and then placed onto dashboards. This distinction matters because the same chart can appear on multiple dashboards, and it can also appear inside a view (as the chart pane you toggle with the bar chart icon at the top right of any view).
To create a chart, navigate to make.powerapps.com and open your solution. In the solution, find the table you want to chart — let's use an Opportunity table with columns like Stage (a Choice column), Estimated Revenue (Currency), and Owner (a lookup to the User table).
From the table's detail page, click the Charts area in the left panel (you may need to look under the table's objects). Click New chart.
The chart editor opens in a split view: a preview pane on the right and a configuration pane on the left. You'll configure three things:
For an "Opportunities by Stage" chart:
Tip
The "Record Count" aggregate is always available regardless of column type. For numeric columns like Estimated Revenue, you can also choose Sum, Average, Min, or Max. A "Sum of Estimated Revenue by Stage" chart is often more useful to sales managers than a count, because it reflects pipeline value, not just deal volume.
Click Save and Close. The chart is now attached to the Opportunity table and can be placed on any dashboard.
The chart editor offers several visual types. Here's practical guidance:
Warning
Line charts require your category column to carry time-based data that Dataverse can group chronologically. If you accidentally use a text column as the X axis on a line chart, the chart will render but the axis order will be alphabetical — which usually produces nonsense. Always verify that the preview looks meaningful before saving.
When you create a system dashboard, you choose a layout first. A layout defines how many component slots exist and how they're arranged on the page — think of it like a page grid. The available layouts range from a single full-width component to a 3-column, 2-row arrangement with six total slots.
Each slot can hold either:
The most common layout for operational dashboards is a 2-column, 2-row or 3-column, 1-row arrangement. This gives you enough space to show two or three charts alongside a list of actionable records — the classic "at-a-glance" pattern.
Let's build a real dashboard for a sales operations scenario. We'll use:
Go to make.powerapps.com, open your solution, and click New → Dashboard → Standard dashboard. You'll be prompted to choose a layout.
Select the 3-Column Overview Dashboard layout. This gives you a top row with three equal-width chart slots and a bottom row with three equal-width list slots.
Name your dashboard something descriptive: Sales Operations Overview.
The dashboard editor shows six empty boxes arranged in the layout you selected. Each box has a small icon in the center — a bar chart icon for chart slots and a list icon for list slots, though in a standard layout you can configure each slot as either type.
Click the bar chart icon inside the first top-row slot. A dialog opens asking you to configure the chart component:
Click Add.
For the second top-row slot, add another chart:
For the third top-row slot, add a chart from the Case table:
Key insight
The view you select when adding a chart to a dashboard acts as a filter. If you select "My Open Opportunities" instead of "All Opportunities," the chart will only count records visible in that view — which means it respects the view's filter conditions. This is a powerful pattern: you can show "This Quarter's Opportunities by Stage" by referencing a view already filtered to Q4.
Click the list icon in the first bottom-row slot. A dialog opens:
This renders a live, scrollable list of the current user's open opportunities directly on the dashboard — no navigation required.
For the second bottom-row slot:
For the third slot, you might pull from an entirely different table — perhaps Tasks with an "Overdue Tasks" view, giving a user a to-do style widget right on the home dashboard.
Click Save in the toolbar, then click Publish. Publishing makes the dashboard visible to users. Until you publish, only you can see it in the editor.
Publishing a dashboard makes it available, but it won't automatically be what users see when they open the app. To set it as the default, you need to configure it inside the app designer.
Open your model-driven app in the App Designer (from your solution, click the app, then click Edit). In the modern app designer, navigate to the Navigation panel. Find the Dashboards area in the site map. If dashboards are enabled in your app's navigation, you'll see the area here.
To set a specific dashboard as the default:
Save and publish the app. Now, when a user navigates to the Dashboards area in your app, they land on the Sales Operations Overview by default rather than on a blank or generic dashboard.
Tip
If you want to surface the dashboard as the very first screen a user sees when opening the app — before they click anything — set the default view in the app's site map to lead with the Dashboards area rather than a specific table. You do this in Configuring Model-Driven App Site Maps: Navigation Areas, Groups, and Subareas for Role-Based Menu Structures by making Dashboards the first subarea in the first group.
A common misconception is that dashboards are static images. They're not — they're interactive in several useful ways.
Chart drilling: When a user clicks a segment of a chart (a bar, a pie slice, a funnel section), the app navigates to a filtered view showing only the records represented by that segment. Click the "Proposal" bar in your "Opportunities by Stage" chart, and you land in a filtered Opportunity view showing only proposals. This is one of the most valuable features of model-driven dashboards and requires zero additional configuration — it works out of the box.
Refreshing data: Users can click the refresh icon on any chart or list to pull the latest data from Dataverse without reloading the whole page.
Switching between dashboards: The dropdown at the top of the dashboard area lists all dashboards the user has access to — system dashboards they've been given access to, plus any personal dashboards they've created. Users can freely switch between them.
List interaction: Records in a list component are clickable. Clicking a row opens the record's form directly. Users can act on records (edit, delete, run workflows) from the list without navigating away first.
Note
Dashboard interactivity depends on the user having appropriate security roles. If a user can see a record in a chart but doesn't have read permission on that record type, clicking the chart segment may show an empty or restricted view. Always test dashboards with a non-admin user account. The Dataverse security model is covered in depth in Dataverse Security: Business Units, Security Roles, and Teams.
System dashboards aren't automatically visible to every user. They follow the same security model as other app components. By default, when you publish a system dashboard, it's visible to all users who have access to the app. But you can restrict visibility by:
This is particularly useful when you have a "Sales Manager Dashboard" with team-wide revenue data that should only be visible to managers, not to individual contributors.
Charts become significantly more useful when the underlying table has Formula Columns and Rollup Columns in Dataverse: Calculated Data Without Code. A rollup column calculates aggregate values — like the total revenue of all related opportunity rows — and stores the result on the parent record. When you chart a rollup column on an Account table, you get aggregated business data in a single chart without any complex query configuration.
For example: if your Account table has a rollup column called Total Pipeline Value that sums Estimated Revenue across all related open opportunities, you can create a column chart with Account as the category and Sum of Total Pipeline Value as the series. This gives you an account-level revenue comparison that would otherwise require complex joins.
Work through this sequence using a real model-driven app in a developer environment:
1. Prepare your data. Make sure your app has an Opportunity table (or equivalent) with at least 10 rows and a Choice column for stage/status. If you're starting fresh, import sample data using the Excel import path described in Importing and Migrating Data into Dataverse: Excel Import, Dataflows, and Upserts.
2. Create three charts on the Opportunity table:
3. Build a system dashboard with a 3-column, 2-row layout. Place all three charts in the top row. In the bottom row, place:
4. Save, publish, and test interactivity. Open the app as a regular user (or use a second browser in InPrivate mode with a different account). Confirm:
5. Set the dashboard as the app default and verify the experience resets to it when navigating to Dashboards.
Chart shows "No data" The most frequent cause is that the view you selected when adding the chart to the dashboard has a filter that returns no records for the current user. For example, "My Open Opportunities" returns nothing if the logged-in user has no opportunities assigned to them. Test with a view that has a broader filter, like "All Opportunities," to verify the chart can render data at all.
Chart data looks wrong or incomplete Remember that charts aggregate the data in the selected view — if the view has a filter condition, only records matching that filter contribute to the chart. Open the view itself and verify how many records it returns for the user experiencing the issue.
Dashboard won't appear in the app If you published the dashboard but it doesn't show in the app, verify that the Dashboards subarea is included in your app's site map. Dashboards are a navigation area that must be explicitly enabled — they don't appear automatically just because a dashboard exists in the solution.
"Opportunities by Stage" chart shows all stages as one color This is a rendering quirk with some chart types. Pie and donut charts automatically color each slice differently. Bar and column charts use a single color series by default. This is expected behavior, not a bug.
Users can't see the system dashboard Check whether security role restrictions are enabled on the dashboard. In the classic solution explorer, open the dashboard and verify "Display to everyone" is selected, or that the user's role is in the enabled list. Also confirm the user has at least Read access to the Opportunity table — a chart over data the user can't see will not render.
Warning
If you delete a view that's being used by a dashboard list component, the list component will display an error for all users. Always check which dashboards reference a view before modifying or deleting it. The classic solution explorer's dependency checker can help surface these relationships.
You've now built a complete picture of how model-driven app dashboards work — from the chart definitions attached to individual tables, to the layout system that assembles those charts and view-based lists into a coherent dashboard, to the publishing and defaulting mechanics that surface it for your users.
The key ideas to carry forward:
From here, there are several natural directions to explore. If your users need data beyond what standard charts can show — custom aggregations, cross-table visualizations, or pixel-perfect layouts — look at Adding Custom Pages to Model-Driven Apps: Canvas Power in a Model-Driven Shell, which lets you embed full canvas app experiences inside the model-driven shell. For more sophisticated visualizations using PCF controls, Extending Model-Driven Apps with PCF Controls: Building and Deploying Custom Field and Dataset Components for Dataverse Forms and Views shows you how to build and deploy fully custom components. And if you want to make the data behind your charts more meaningful through calculated aggregates, revisit Formula Columns and Rollup Columns in Dataverse: Calculated Data Without Code to add pre-calculated metrics to your tables before charting them.
Model-Driven Apps & Dataverse
Designing Dataverse Hierarchical Relationships and Rollup Security: Modeling Parent-Child Table Hierarchies, Hierarchical Security Roles, and Visualizing Tree Structures in Model-Driven Apps
Configuring Dataverse Table Permissions in Model-Driven Apps: Mapping Security Roles to Tables, Privileges, and Access Levels for New Makers