Learn how to build system charts and multi-panel dashboards in model-driven apps that visualize Dataverse data in real time. This lesson covers chart configuration, dashboard composition, role-based design, and knowing exactly when to reach for Power BI instead.
Your sales manager walks into a meeting and asks: "How many open opportunities do we have by stage, and which reps are closing the most deals this quarter?" Without analytics built into your app, answering that question means exporting data to Excel, building a pivot table, and hoping the numbers are still accurate by the time the slides are ready. That's a painful workflow, and it's one that model-driven apps are specifically designed to eliminate.
Model-driven apps include a surprisingly capable built-in analytics layer — charts and dashboards — that lets users visualize Dataverse data directly inside the app, updated in real time as records change. These aren't just decorative bar charts. They're interactive, filterable visualizations that sit alongside your views and forms, giving users instant insight without leaving the application. When configured thoughtfully, they transform a data entry tool into a genuine operational dashboard.
By the end of this lesson, you'll know how to create system charts for individual tables, assemble multi-panel dashboards from charts and views, and publish them so users see relevant analytics from the moment they open the app. You'll also understand the limitations of the built-in analytics layer — so you know exactly when to reach for Power BI instead.
What you'll learn:
You should be comfortable navigating the Power Apps maker portal and have a basic understanding of how model-driven apps are structured — tables, views, and forms. If you're new to those concepts, start with Building Your First Model-Driven App: Site Map, Tables, Forms, and Views before continuing here.
It also helps to understand what Dataverse tables and columns are, since charts are always built against a specific table. Dataverse Fundamentals: Tables, Columns, and Rows Explained for Power Apps Makers has you covered if that's unfamiliar territory.
Before you click anything, it's worth understanding the mental model. In a model-driven app, a chart is always associated with a specific Dataverse table. It's not a standalone object — it lives in the context of a view on that table. This is actually a strength: when a user filters a view (say, showing only opportunities owned by a particular rep), the chart updates to reflect the filtered dataset. The chart and the view are always synchronized.
A chart answers two questions: what to measure (the series — usually an aggregate like count or sum) and how to group it (the category — usually a choice column, lookup, or date field). For example:
That gives you a bar chart showing how many opportunities exist at each stage. Swap the series to "Sum of Estimated Revenue" and suddenly you're looking at pipeline value by stage — same chart structure, completely different business insight.
Charts are stored as XML definitions in Dataverse and travel inside solutions, which means they're deployable across environments just like everything else in your app.
Note
There are two types of charts in model-driven apps — user charts (personal, only visible to the creator) and system charts (available to everyone with access to the table). For anything you want to share with your team or include in a dashboard, you need a system chart. This lesson focuses on system charts.
Let's work through a realistic scenario. You're building a service management app with a Case table. Managers want to see case volume by priority (High, Medium, Low) and case status (Active, Resolved, Cancelled). You'll build charts for both.
This opens the chart designer — a split-pane editor with configuration on the left and a preview on the right. The preview updates as you make changes, which is genuinely useful for iterating quickly.
The chart designer has two main sections:
Series (what you're measuring):
Category (how you're grouping):
Chart type: Use the chart type selector at the top. For distribution across categories, Bar or Column charts work well. For proportional breakdowns, Pie and Donut charts are readable. For trends over time, Line charts shine.
For case volume by priority, a Column chart (vertical bars) is a natural choice.
Name your chart something descriptive: "Cases by Priority" rather than "Chart 1." This name appears in the chart picker inside the app.
Click Save and Close when you're done.
Tip
After saving your chart, go back to the Charts list and create a second one: "Cases by Status" using the Status Reason column as the category. Having multiple charts on the same table lets users switch between them using the chart picker inside the app — it's a small feature that makes a big usability difference.
To see your chart in action, open your model-driven app (either from the Apps list or directly from the maker portal). Navigate to the Cases section. In the main list view, look for the Show Chart button in the command bar — it looks like a small bar chart icon. Clicking it splits the screen: the view on the left, the chart on the right.
A dropdown at the top of the chart panel lets users switch between all system charts for that table. Try filtering the view (for example, show only High priority cases) and watch the chart update automatically. That real-time synchronization is what makes this genuinely useful for operational oversight.
The built-in chart editor is intentionally simple. It handles single-series aggregations well, but it has real constraints you should know about upfront:
If you've used Formula Columns and Rollup Columns in Dataverse: Calculated Data Without Code to pre-calculate values in Dataverse, those columns are available in the chart editor. This is a useful pattern: push the calculation into Dataverse as a formula or rollup column, then surface it in a chart without needing complex query logic.
Key insight
Think of model-driven app charts as operational indicators for people working in the app — not as analytical reports for executives. They answer "what does my current workload look like right now?" rather than "what happened over the last 18 months?" For the latter, Power BI is the right tool.
A dashboard in a model-driven app is a configurable page made of panels. Each panel can contain a chart, a view (list of records), an iframe (embedded web content), or a web resource. Dashboards are the composition layer — they bring together charts from multiple tables onto a single screen.
Think of a dashboard as a manager's morning briefing page: open the app, see case volume, open opportunities, and today's activities — all in one place, no navigation required.
In the maker portal, go to the left navigation and select Dashboards under your solution, or navigate through Apps → (your app) → Edit → Pages depending on your model-driven app version.
The clearest path: go to the Solutions area, open your solution, and look for Dashboard under the component types. Click New → Dashboard.
You'll be prompted to choose a layout. Layouts define how many panels appear and how they're arranged. Common options include:
For our service management example, choose 2-Column Regular Dashboard to start. You can always delete and recreate with a different layout — the component configuration doesn't transfer between layouts.
Give your dashboard a meaningful name: "Service Manager Overview."
Each empty panel in the layout shows a small icon toolbar. You'll see icons for:
Click the chart icon in the first panel. A dialog appears:
Click Add and the chart appears in that panel.
Click the list icon in the second panel and configure it similarly: choose the Case table and a view like "My Active Cases." Now managers see the chart on one side and the underlying records on the other.
Warning
The View you select when adding a chart panel to a dashboard matters more than most people realize. If you pick a view that's filtered to "My Cases," the chart will only ever show data for the current user — which is usually wrong for a manager-level dashboard. Use a view scoped to the full dataset your audience should see, like "All Active Cases."
Click Save at the top, then Close. Back in the solution, find your new dashboard component and make sure it's included in your model-driven app's pages.
To add it to the app:
By default, when users open the app's home area, they see the most recently viewed dashboard. You can override this by setting a default dashboard — a specific dashboard that appears for all users when they first open that area.
To set the default:
Note
The default dashboard is set per user role/app combination and stored in the system. Individual users can switch to a different dashboard and it'll remember their choice, but new users always start with the default. This is important for onboarding — a well-designed default dashboard immediately shows new users that the app is configured for their work, not just a blank list of records.
One of the most useful — and underutilized — features of model-driven app charts is their interactivity. When a user clicks a bar, slice, or data point in a chart, the app filters the adjacent view to show only the records that make up that segment.
For example: a manager sees the "Cases by Priority" chart and notices the High priority bar is unusually tall. They click that bar. The view on the left instantly filters to show only High priority cases. From there, they can open individual records, assign them, or apply bulk updates. The chart becomes a navigation tool, not just a display.
This behavior is automatic — you don't configure it. But it's worth explicitly demonstrating to users, because many assume charts are decorative. The drill-down behavior is what makes these charts genuinely operational.
Different users need different dashboards. Your service agents want to see their own open cases and average response times. Your service managers want to see team workload distribution and SLA compliance rates. Your operations director wants volume trends over time.
The approach in model-driven apps is to create multiple system dashboards and configure which one is appropriate for each audience. You can combine this with the Configuring Model-Driven App Site Maps: Navigation Areas, Groups, and Subareas for Role-Based Menu Structures patterns — putting a manager-specific dashboard in a navigation area that's only visible to users with the manager security role.
The views you use as chart data sources are also affected by security roles. If a user's security role only grants access to their own records, the chart will automatically reflect that — the underlying Dataverse query respects row-level security without any extra chart configuration.
Tip
When designing dashboards for different roles, start by interviewing the people who'll use them. Ask: "What's the first thing you need to know when you start your day?" and "What number, if wrong, would ruin your morning?" Those two questions usually identify the two most important chart panels for any given audience.
This exercise assumes you have a model-driven app connected to a Dataverse environment with at least one table that has several records. The Case table from a trial Dynamics 365 Customer Service environment works perfectly, but any table with 20+ records and a Choice column will do.
Step 1: Create two system charts
Navigate to your table's Charts section and create:
Step 2: Verify charts in the app
Open your model-driven app, navigate to the table's view, and click the Show Chart button. Confirm both charts appear in the chart picker. Click a bar or slice and verify the view filters.
Step 3: Build a dashboard
In your solution, create a new 2-Column Regular Dashboard named "[Your Name] Operations Overview." Add:
Step 4: Add the dashboard to your app
Open the app designer, add a Dashboard subarea pointing to your new dashboard, save, and publish. Open the app and set your dashboard as the default.
Step 5: Reflect
Open the dashboard and ask yourself: Does this tell a coherent story? Is the view scope right (too narrow? too broad)? Would someone unfamiliar with the data understand what they're looking at? Adjust labels, view selections, and chart types based on your answers.
"My chart shows no data." Check the view you associated with the chart panel. If it's a personal view or a view filtered to criteria that match zero records in your environment, the chart will be empty. Switch to a system view like "Active Cases" and confirm records exist.
"The chart doesn't update when I filter the view." Charts only sync with the view when the chart is displayed in the split-screen mode on a view page — not when embedded in a dashboard. Dashboard panels have their own view scope, set when you add the panel. The two experiences (view + chart vs. dashboard panel) are separate.
"I can't find my chart in the dashboard chart picker." The chart must be a system chart, not a personal chart. If you created it while logged in as a user and it saved as a personal chart, it won't appear in the dashboard configuration. Create charts from the solution explorer or the table's Charts tab in the maker portal to ensure they're system charts.
"My dashboard panel is showing data from the wrong user's records." You've used a view scoped to "My [Records]" — a view filtered to the current user. For team-level dashboards, always use views with broader scopes like "Active [Records]" or create a dedicated view without owner filters.
"The chart type dropdown is missing some options." Not all chart types work with all data configurations. Funnel charts, for example, require a specific ordering column. If an option is grayed out, it means the current series/category combination doesn't support that chart type.
"Users on mobile can't see the dashboard properly." Dashboard rendering on mobile (Power Apps mobile app) is functional but limited — some complex dashboard layouts collapse or truncate. Test your dashboards on the target device early, not as an afterthought.
You've covered the full arc of built-in analytics in model-driven apps: from understanding why charts are always table- and view-scoped, to creating system charts with specific series/category configurations, to assembling dashboards that give different users the right operational snapshot the moment they open the app.
The core pattern to remember: views scope the data, charts visualize it, dashboards compose it. Getting the view selection right is the most important single decision in both chart and dashboard configuration. A beautifully designed chart showing the wrong dataset is worse than no chart at all — it creates false confidence.
The built-in analytics layer is genuinely powerful for operational use cases. When users need to answer "what's happening right now in my work queue?" these tools deliver. When the need shifts to trend analysis, cross-environment comparison, or executive-level reporting, it's time to embed a Power BI report — which you can do through an iframe panel in a dashboard or through the more sophisticated Power BI embedded integration.
As you continue building out your model-driven app, consider how Creating and Customizing Views in Model-Driven Apps: Filters, Sorting, and Editable Grids affects what data your charts can surface — well-designed views are the foundation of useful analytics. And if you're thinking about who should see which dashboards, the principles in Model-Driven App Security: Configuring Security Roles, Field Permissions, and Team-Based Access for Table Data will help you gate access appropriately.
Model-Driven Apps & Dataverse