Visualizing Aggregated Data Beside a Row List in Power Apps
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?
Community Insight
The question tests which Power Apps component produces an aggregated visual that displays in parallel with a row list — a system chart — and the trap is choosing app-level settings, navigation, or a custom page instead of a chart bound to a view.
In a model-driven app, a system chart delivers the aggregated, graphical representation of business performance data that managers need, and it renders in a chart pane directly alongside the selected view (list of rows). This page establishes that creating a system chart is the correct configuration step for side-by-side visual insight.
Choosing D (Add a custom page to the app) is the most common wrong pick: a canvas-based custom page can display visuals, but it does not render in parallel with the model-driven view of rows and it must be built and embedded rather than simply configured, so it does not satisfy the 'directly within the app, viewed in parallel with a list of rows' requirement as cleanly as a system chart.
Community Discussion (1 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
A system chart is the native model-driven app mechanism that aggregates rows (sum, average, count, grouping) and renders a graphical representation in the chart pane next to the selected view, exactly matching the requirement to see visuals "in parallel with a list of rows." Charts are tied to views and to the row data on screen, so managers see the aggregated performance picture beside the underlying list without leaving the app. Creating a system chart makes it available app-wide for any user with access to the view, which satisfies the company-wide rollout implied by the scenario.Why the Other Options Are Wrong
A. Modify app settings changes app-level behavior such as form selection, offline, or navigation modes, and none of these produce an aggregated visual representation of data. B. Configure app navigation only controls how users move between areas, sitemaps, and views; it adds no charting or aggregation capability. D. Add a custom page to the app embeds a canvas experience that would require you to author charts yourself and would not automatically sit beside the model-driven list of rows, making it an over-engineered and misaligned choice for a straightforward visual insight requirement.Community Comment Notes
The single community comment selected the same option, stating simply "C. Create a system chart." with no supporting caveats, which aligns with the model-driven app design pattern for side-by-side visualization. Since no dissenting comments were posted, the vote record offers no counter-argument to weigh, and the verdict rests on the documented behavior of charts in model-driven apps.Official Reference
Exam Strategy
On scenario questions, key off phrases like "in parallel with a list of rows" — in model-driven apps only charts share the screen with a view. If a question asks for visuals beside rows, pick the chart option; reserve custom pages for cross-app or bespoke canvas experiences.
Frequently Asked Questions
Why is adding a custom page not the right way to show data beside a list?
A custom page is a separate canvas surface that must be built and embedded; it does not automatically render alongside the model-driven view of rows. A system chart already provides the parallel chart pane.
Do system charts only work with one specific view?
A chart is created against an entity and paired with a view, so it displays next to whichever view is active. Managers can switch views while the chart updates to reflect the filtered rows.