Reports and dashboards are where Salesforce data becomes operational information. A report answers a structured question about records; a dashboard combines report results into visual components that help users see patterns, targets, exceptions, and trends. The current Salesforce Platform Administrator exam includes data and analytics management as 17% of the blueprint, making reporting skills a core administrator capability rather than an optional analytics specialization.
Salesforce’s current public credential name is Salesforce Certified Platform Administrator. The approved ExamTopics.info inventory uses the familiar adm-201 page, while the broader Salesforce certifications destination provides ecosystem context. For administrators, the practical objective is to build reporting that answers the business question without accidentally exposing more data, hiding important exceptions, or presenting a metric whose definition nobody can explain.
A report starts with the records and relationships available to the report type
Every Salesforce report is based on a report type. Standard report types expose common object relationships, while custom report types let administrators define which related records are available. If the report type does not represent the relationship the business question needs, no amount of filtering or chart formatting will create the missing data model.
That is why strong reporting begins before the report builder. Identify the entity being measured, the relevant related records, and whether the business wants “with” relationships, “with or without” relationships, or a more specific custom combination. For example, a sales leader asking for accounts with and without open opportunities needs a different perspective from someone asking only for open opportunities grouped by account.
Good administrators distinguish a reporting limitation from a data-model limitation. Sometimes the answer is a custom report type; sometimes the underlying data relationship needs redesign.
Report performance also matters. Extremely broad reports with many complex formulas, cross filters, or large unselective datasets can become slow and discourage adoption. Administrators should narrow the dataset to the business question, use selective filters where possible, and avoid asking one report to serve every audience at once.
filters define the population before metrics summarize it
A report can be mathematically correct and still be misleading if the filtered population is wrong. Date ranges, ownership filters, record types, status values, and cross filters determine which records are included before grouping and formulas are evaluated. Administrators should make filter intent visible enough that consumers know what the report excludes.
Relative date filters are powerful for rolling windows, but they change automatically over time. A “current quarter” report is appropriate for an operating dashboard, while a regulatory or audit snapshot may need a fixed date range. Likewise, filtering on “My Opportunities” produces a different governance model from showing all records the running user can access.
A broad analytics foundation reinforces the same principle: a metric is only meaningful when the underlying population and definitions are clear.
Row-level formulas calculate a value for each record in the report, while summary formulas operate on grouped results. Choosing the wrong formula type can produce a plausible-looking but incorrect metric. Administrators should validate formulas with a small known dataset before publishing them to executives.
tabular, summary, matrix, and joined structures serve different questions
Tabular reports present rows with limited grouping and are useful for lists or exports. Summary reports group rows by one or more fields and are a common foundation for charts and dashboards. Matrix reports group by both rows and columns, making them useful for comparisons such as revenue by region and quarter. Joined reports combine multiple report blocks so related perspectives can be viewed together.
The best format is the one that makes the business question easier to understand. Adding a matrix because it looks sophisticated can make a simple operational report harder to use. Likewise, a long tabular list may hide the pattern a manager really needs to see.
Administrators should design from the decision backward: what will a user do differently after seeing the report? The presentation should reduce the effort required to reach that decision.
Custom summary formulas can also depend on grouping level. A ratio that is meaningful at the team level may not aggregate correctly to the company level if the numerator and denominator are not designed carefully. When in doubt, test every subtotal and grand total rather than checking only one group.
grouping and summary formulas turn records into management information
Grouping gives context to totals. A count of opportunities means little until users know whether it is grouped by owner, stage, region, product, or time period. Summary fields such as sums, averages, minimums, maximums, and row counts provide standard aggregation, while summary formulas can calculate ratios or other derived measures.
Formula design requires care because the denominator matters. A win rate based on closed opportunities is different from a ratio that includes every open opportunity. A service metric can look better or worse depending on whether cancelled cases are included. The administrator should document or encode the intended population so the number is not reinterpreted every time a manager changes.
The broader lessons from business intelligence reporting apply even though the tools differ: trustworthy analytics comes from clear definitions, useful dimensions, and correct aggregation.
Dashboards should use visual encodings appropriate to the measure. Gauges are useful when a metric has a meaningful target range; bar charts support category comparison; line charts are strong for trends; tables are better when users need exact values. Visual variety is not a goal by itself.
dashboards visualize report results, not independent data
A Salesforce dashboard is built from source reports. Components can show charts, gauges, tables, metrics, and other visualizations around a common theme. Because the dashboard depends on reports, a broken filter or weak report definition propagates directly into the visual layer.
Dashboard design should prioritize a small number of decisions. A sales dashboard might show pipeline value, closed revenue, stalled opportunities, and top accounts. A service dashboard might focus on backlog, response time, escalations, and aging. Filling every available space with a component can make the dashboard less useful because the important signal no longer stands out.
Salesforce also supports dashboard filters so users can change a common dimension across components. Filters are valuable when the reports are designed consistently enough that the same field or equivalent grouping applies across them.
Refresh behavior should be part of the user’s expectation. Dashboard components show data from their source reports at a point in time, and cached or scheduled refresh behavior can affect what viewers see. If a metric is used for operational response, administrators should make sure its freshness matches the decision cadence.
running users and dynamic dashboards control which data viewers see
Dashboard visibility is not determined only by folder access. A standard dashboard has a running user whose security settings determine the data displayed to viewers. If a highly privileged user runs the dashboard, viewers may see aggregated results that reflect that user’s broader record access.
A dynamic dashboard uses the logged-in viewer as the running user, so each user sees data according to their own access. This can be useful for reusable team dashboards where one design should adapt to different managers or representatives. Availability depends on edition and limits, so administrators should know the org’s capabilities before promising a dynamic design.
Security-aware reporting connects directly to Salesforce Business Analyst work because stakeholders often ask for “the same dashboard” while having very different data-access entitlements.
Sharing official reports also creates change-control questions. If many leaders depend on one report, an administrator should not casually edit filters or formulas in place. Cloning for experimentation and documenting material changes protects consumers from silent definition drift.
folders control report and dashboard content access
Reports and dashboards are stored in folders. Folder sharing determines who can view or manage the report assets, while underlying record access determines which business data a user can see when running them. Those are separate layers. Giving someone access to a report folder does not automatically grant access to every record referenced by the report.
Salesforce’s enhanced folder sharing distinguishes Viewer, Editor, and Manager levels. Administrators should grant the least capability required. A user who only needs to run a report does not necessarily need permission to edit or redistribute it.
Folder design also supports governance. Separating executive, departmental, operational, and personal content makes it easier to identify which assets are official. A dashboard should not become a de facto source of truth merely because someone bookmarked it.
Subscription and notification features can push report results to users, which is useful when an exception requires attention. But automated delivery should be configured thoughtfully so users are not flooded with reports they stop reading. A notification is valuable when it signals an action, not merely because a schedule exists.
reporting quality depends on data quality and consistent business definitions
A dashboard cannot correct duplicate accounts, missing close dates, inconsistent stage usage, or badly maintained ownership. In fact, visualizations can make poor data look more authoritative. Administrators should pair reporting projects with data-quality checks and with clear definitions for important fields.
When two teams disagree about a metric, the problem may not be the report builder. They may use different definitions of “active customer,” “qualified lead,” or “at risk.” The right response is to resolve the business definition and then encode it consistently in fields, formulas, filters, or reporting logic.
This is why data administration and analytics are linked. A well-governed data lifecycle improves not only security but also the reliability of decisions made from reports.
Reporting security should be tested with real personas. An administrator can see almost everything, so a dashboard that appears correct in an admin session may behave very differently for a sales representative, partner user, or manager. Testing with representative permission sets and roles reveals those differences before launch.
Report consumers should also understand the difference between data visibility and metric ownership. An administrator can build the mechanics of a churn report, but the business owner should define what qualifies as churn and when that definition changes. Assigning ownership to critical metrics prevents a future admin from changing a filter based only on a support ticket and unintentionally rewriting historical meaning.
Historical trending can require storing snapshots or using features designed for history because a standard report usually reflects current record state. If management asks “what did the pipeline look like at the end of every month?” a report on today’s opportunities cannot reconstruct all prior values unless history was captured. Reporting requirements should therefore identify whether the question is about current state, change history, or point-in-time snapshots.
Joined reports can be helpful when a business question spans related but different report blocks, but they are not a replacement for a coherent data model. If every executive question requires elaborate joined reports, the underlying object relationships or analytics architecture may need review. Administrators should solve the reporting need without masking structural data problems.
Dashboards should also distinguish leading and lagging indicators. Closed revenue is a lagging result, while pipeline coverage or aging opportunities can signal future outcomes. A balanced dashboard combines results with actionable drivers so managers can intervene rather than simply observe what already happened.
Time-based analysis needs special care because ordinary reports usually answer questions about the current state of records. If leadership wants to know how pipeline, backlog, or case volume changed from week to week, the administrator may need historical data, reporting snapshots, or another mechanism that preserves prior states instead of repeatedly querying today’s values. Without that distinction, a chart can look like a trend while actually comparing records that have already changed. Good reporting design therefore starts by asking whether the business question is about the present, a sequence of past states, or transactions that occurred during a period.
Filters also need a shared business interpretation. “Closed this quarter,” “active customer,” or “open pipeline” can sound obvious while different teams apply different date fields, stages, ownership rules, or exclusions. Administrators should document important report definitions and reuse them consistently when several dashboards feed the same management process. That practice reduces arguments about whose number is correct and keeps reporting changes visible. A technically valid report is not automatically a trustworthy management instrument; users need confidence that the population, grouping, security context, and calculation rules match the decision the report is intended to support.
Platform Administrator scenarios reward fit-for-purpose reporting
Exam scenarios often provide a business need and ask for the appropriate reporting feature. If a manager needs a list, a tabular or summary report may be enough. If users need to compare two dimensions, a matrix report may fit. If executives need visual indicators from several reports, a dashboard is appropriate. If each manager should see only their own accessible records from one shared design, a dynamic dashboard may be the key concept.
A useful lab is to build one report from a standard report type, one from a custom report type, add grouping and a summary formula, store them in a shared folder, then build a dashboard and test it with users at different access levels. Observe both what the user can open and what data the report returns.
For platform context, the inventory’s Salesforce Classic transition helps explain why current administrator practice centers on Lightning Experience reporting, while current Trailhead preparation explicitly includes reports, dashboards, data analysis, and data visualization.
Report design should begin with the decision the audience needs to make. A sales manager may need pipeline movement by stage and owner, while an operations team may care about aging, backlog, and exception rates. Starting from the business question helps the administrator choose the correct report type, filters, grouping, and summary measures instead of building a visually attractive dashboard that answers no specific question.
Data quality is part of reporting accuracy. A chart can be technically correct and still be misleading when required fields are sparsely populated, picklist values are inconsistent, or historical changes are not captured. Administrators should validate the meaning of the underlying fields with process owners and make report assumptions explicit. When a metric depends on a formula or joined relationship, test several known records manually before trusting an aggregate result.
Dashboard maintenance also needs ownership. Filters, source reports, folder access, and business definitions change over time. A useful operational pattern is to assign an owner to important dashboards, review them on a regular cadence, remove obsolete components, and confirm that the intended audience can still see the underlying records. This prevents executive reporting from quietly drifting away from the process it is supposed to represent.