Visualize Data Alongside Rows in a Model-Driven App
Short answer
D Create a system chart on the table so aggregated visuals display in the chart pane alongside the list of rows in the app.
Question
A company wants to provide managers with visual insights into business performance data. Managers require aggregated and visual representations of data directly within the app to be viewed in parallel with a list of rows. You need to configure the visual representation of data. What should you do?
Key Takeaways
The question tests in-app visual aggregation shown in parallel with a list of rows; the trap is choosing an option that is either a separate page, a plain list, or an underlying data model rather than a rendered chart.
To give managers aggregated, visual data next to a list of rows inside the app, you create a system chart on the table and display it with the view. This page explains why a system chart satisfies the requirement while a custom page, default view, or Power BI semantic model does not.
Common mistake: The most common wrong pick is A (add a custom page), because a custom page is a separate canvas-style surface that opens apart from the view, so it does not display the visual representation in parallel with the list of rows.
Expert Analysis
Why the Answer Is Correct
Creating a system chart (option D) produces an aggregated, visual representation—bar, pie, line, or funnel—defined on the table itself. In a model-driven app, charts render in the chart pane directly alongside the active view, so managers see the visuals in parallel with the list of rows exactly as required. System charts are stored with the table, are available to anyone using the app, and support switching charts against the same filtered data set.Why the Other Options Are Wrong
A custom page (A) is a separate Power Apps page that opens on its own and does not render beside the rows of a view, failing the 'in parallel with a list of rows' requirement. Specifying a default view (B) only controls which row list loads first; a view is a list of columns and filters, not an aggregated visual. Creating a Power BI semantic model (C) builds an underlying data model for reporting—it produces no in-app visual by itself and would still require a report or embedded visual to be seen, which is not what the question asks for.Community Comment Notes
The single community vote agrees with the verdict, with exam_upskill answering "D. Create a system chart." That aligns with the model-driven app design pattern where charts are the native mechanism for side-by-side visual insight against a view. No dissenting comments were posted, so there is no conflicting learner reasoning to reconcile.Official Reference
Exam Strategy
Key in on the phrase 'in parallel with a list of rows'—that is the signature of the model-driven chart pane tied to a view. Eliminate anything that opens separately (custom page), is only a list configuration (default view), or is a backend model (semantic model), and choose the native table chart.
Frequently Asked Questions
Why isn't adding a custom page the right way to show visuals beside the row list?
A custom page is a separate surface that opens apart from the view, so it doesn't render in parallel with the list of rows. A system chart displays directly in the chart pane next to the active view.
Why does a Power BI semantic model not satisfy this requirement?
A semantic model only defines the underlying data structure for reporting; it produces no visual by itself. The question needs an in-app rendered visual, which a system chart provides natively.
Discussion 1 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded.
From public community threads 1
-
exam_upskill 👍 2 Answered DD. Create a system chart.
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.