Study guide
2.4 Reports, Custom Report Types & Dynamic Dashboards
Salesforce Certified Platform App Builder Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Platform Architecture, Boundaries & Extensions
1.1 Declarative vs. Programmatic Architecture & Limits 1.2 AppExchange Solutions & Package Selection 1.3 Core CRM Standard Objects & Capabilities
2 Chapter 2: Security, Access & Analytics
2.1 Object-Level & Field-Level Security 2.2 Record-Level Sharing Architecture 2.3 Advanced Sharing & Scoping Solutions 2.4 Reports, Custom Report Types & Dynamic Dashboards
3 Chapter 3: Data Model Architecture & Relationships
3.1 Custom Objects & Custom Field Types 3.2 Master-Detail & Lookup Relationships 3.3 Many-to-Many Relationships & Junction Objects 3.4 Schema Builder & Data Architecture Visualization
4 Chapter 4: Data Management & External Integrations
4.1 Field Type Conversions & Data Loss Considerations 4.2 Data Import Wizard vs. Data Loader 4.3 Salesforce Connect, External Objects & Indirect Lookups
5 Chapter 5: Declarative Formulas & Validation Rules
5.1 Cross-Object Formulas & Advanced Formula Functions 5.2 Roll-Up Summary Fields & Calculation Rules 5.3 Validation Rules & Error Handling Strategies
6 Chapter 6: Salesforce Flow Architecture & Design
6.1 Flow Fundamentals & Flow Trigger Types 6.2 Record-Triggered Flows: Fast Field Updates vs. Actions 6.3 Screen Flows & Guided User Interactions 6.4 Flow Execution Architecture, Bulkification & Fault Paths
7 Chapter 7: Complex Automation & Approval Processes
7.1 Multi-Step Approval Processes & Approver Routing 7.2 Approval Actions, Rejections & Record Locking 7.3 Automation Selection Strategy & Legacy Migration Patterns
8 Chapter 8: Lightning App Builder & Page Customization
8.1 Lightning Record, Home & App Pages 8.2 Standard, Custom & AppExchange Lightning Components 8.3 Custom Buttons, Web Links & Quick Actions
9 Chapter 9: Dynamic UI, Record Types & Mobile Experience
9.1 Dynamic Forms & Conditional Component Visibility 9.2 Dynamic Actions & Page Interaction Patterns 9.3 Record Types, Business Processes & Picklist Control 9.4 Salesforce Mobile App Customization & Compact Layouts
10 Chapter 10: Application Lifecycle Management & Sandboxes
10.1 Application Lifecycle Management (ALM) Stages & Governance 10.2 Sandbox Types, Capacity & Refresh Cycles 10.3 Sandbox Strategy for Development, Testing & Training
11 Chapter 11: Deployment Tools & Packaging Strategies
11.1 Inbound & Outbound Change Sets 11.2 Change Set Dependency Tracking & Deployment Sequencing 11.3 Managed vs. Unmanaged Packages & Distribution
12 Current Exam Blueprint, Agentforce & Flow Operations
12.1 Current Exam Facts, Official Weights & Study Mapping 12.2 AgentExchange: Extending an Org with the Agentforce Marketplace 12.3 Agentforce Automation for App Builders 12.4 Flow Approval Processes, Monitoring & Troubleshooting
2.4 Reports, Custom Report Types & Dynamic Dashboards
Key Takeaways Explain This Topic AI
Salesforce provides four distinct report formats: Tabular (simple lists), Summary (grouped by rows), Matrix (grouped by rows and columns), and Joined (multi-block comparative analysis).
Custom Report Types govern data visibility by defining object relationship joins (inner join 'with' vs left outer join 'with or without') and allowing lookup field inclusion up to 4 levels deep.
Row-level formulas evaluate record-specific criteria (limit 1 per report), whereas Summary formulas evaluate grouped aggregates (limit 5 per report) using functions like PARENTGROUPVAL and PREVGROUPVAL.
Dynamic Dashboards run as the logged-in user to show personalized data based on each viewer's individual sharing permissions, but cannot be scheduled for email delivery.
Access to shared report/dashboard artifacts uses Folder Sharing together with the relevant system permissions with Viewer, Editor, or Manager access levels, rather than at the individual artifact level.
Last updated: October 2026
2.4 Reports, Custom Report Types & Dynamic Dashboards
Data analytics in Salesforce allows stakeholders to monitor key performance indicators, discover trends, and make evidence-based business decisions. Building effective analytics requires an app builder to master report formats, understand how Custom Report Types dictate data availability, implement formula calculations, and configure Dynamic Dashboards while adhering to platform boundaries.
The Four Core Report Formats
Salesforce Report Builder supports four foundational report formats, each serving distinct analytical requirements:
Tabular Reports : The simplest report format. Presents a flat list of records with selected columns, similar to a spreadsheet. Tabular reports do not group data or show group subtotals. A row-limited tabular report can be used as a dashboard source with the appropriate dashboard settings; adding a row limit does not turn it into a grouped report. Best suited for contact lists, mailing lists, and data exports for Data Loader.
Summary Reports : The most widely utilized format. Rows are grouped by one or more fields (up to 3 grouping levels, such as grouping Opportunities by StageName and then by FiscalQuarter ). Supports subtotals, grand totals, summary formulas, and visual charts.
Matrix Reports : Groups records by both rows and columns in a two-dimensional grid (e.g., grouping Opportunities by StageName along the rows and by CloseDate month along the columns). Ideal for comparing volume and monetary values across two intersecting dimensions.
Joined Reports : Combines up to 5 separate report blocks in a single consolidated view. Each block can use a different report type, apply its own filters, and display its own columns, provided the blocks share common grouping fields (e.g., displaying open Support Cases in Block 1 and Closed Opportunities in Block 2, both grouped by AccountName ).
Custom Report Types (CRT)
Standard report types are generated automatically by Salesforce, but they impose strict limitations: their available objects and relationship behavior are predefined. They can include custom fields; inspect the selected type rather than assuming every standard report is an inner join. When business analysis requires complex multi-object relationships or fields from remote parent objects, an app builder must build a Custom Report Type (CRT) .
Primary and Related Object Hierarchy
A Custom Report Type defines a primary object and can navigate up to 4 levels of related objects (e.g., Object A -> Object B -> Object C -> Object D ).
For each related object relationship, the architect defines the join logic:
"Each A record must have at least one related B record" (Inner Join) : An A record appears in the report only if it has a matching child B record. If an Account has zero Contacts, it will not appear on an "Accounts with Contacts" report.
"A records may or may not have related B records" (Left Outer Join) : All A records appear in the report, regardless of whether any related B records exist.
Important
A standard exam question asks: "How can a marketing director see a report of all Accounts, including those that have NO Opportunities?" An Opportunities-based source excludes Accounts without Opportunities; choose a source that includes the required parent records. The app builder must create a Custom Report Type with Accounts as Object A and Opportunities as Object B, selecting "A records may or may not have related B records" .
Field Layout Management in CRT
The Custom Report Type layout editor provides immense declarative power:
Add Fields Related via Lookup : You can navigate up lookup relationships (up to 4 levels away ) to pull fields onto the report layout. For example, on a Case report type, you can add fields from Case -> Account -> Owner -> User Role .
Custom Display Labels : You can rename a field's display label on the report layout without altering the underlying database field label in Object Manager.
Default Columns : You can specify which fields appear as default selected columns whenever a user creates a new report using that report type.
Advanced Calculations: Bucketing and Formulas
Salesforce provides three distinct mechanisms to calculate or categorize data directly within the reporting layer without adding custom formula fields to the underlying database schema.
Calculation Type Evaluation Scope Platform Limit Requires Grouping? Primary Use Case
Bucket Field Evaluates individual record values to assign categories Up to 5 per report No Grouping picklist values or numerical ranges (e.g., Deal Size: Small, Medium, Large)
Row-Level Formula Evaluates logic row-by-row on individual records Exactly 1 per report No Calculating date differences or line-item margins on a single record
Summary Formula Evaluates aggregated groupings and grand totals Up to 5 per report Yes (Summary/Matrix) Calculating percentages of subtotals ( PARENTGROUPVAL ) or period-over-period trends ( PREVGROUPVAL )
Advanced Summary Formula Functions
Summary formulas allow architects to compute complex ratios across report groupings using two specialized functions:
PARENTGROUPVAL : Returns the value of a summary metric from a parent grouping level or grand total. Commonly used to calculate a category's percentage contribution to overall revenue: AMOUNT:SUM / PARENTGROUPVAL(AMOUNT:SUM, GRAND_SUMMARY)
PREVGROUPVAL : Returns the value of a summary metric from the previous group in a chronological sequence. Commonly used to evaluate month-over-month sales growth.
Dashboards: Components, Filters & The Running User
A Dashboard provides a visual representation of report data using charts (bar, column, line, donut), gauges, metrics, and Lightning tables. Dashboards are powered entirely by underlying source reports; a dashboard component cannot query the database directly.
The Running User Architecture
The Running User determines whose security and sharing permissions are used to query the underlying data when the dashboard is rendered:
Run as Specified User (Static Dashboard) : All dashboard viewers see data based on the single designated user's security permissions, regardless of their own personal access. For example, if a dashboard runs as the VP of Sales, all sales representatives viewing the dashboard see company-wide revenue metrics, even if their individual OWD is Private.
Run as Logged-In User (Dynamic Dashboard) : The dashboard renders data dynamically based on the specific viewer's personal sharing permissions and role hierarchy level. When a regional sales rep opens the dashboard, they see only their opportunities; when the regional director opens it, they see all opportunities in their region.
Critical Limits on Dynamic Dashboards
Organization Limits : Enterprise Edition organizations are limited to 5 Dynamic Dashboards ; Performance and Unlimited Editions receive 10 Dynamic Dashboards .
No Scheduled Subscriptions : Dynamic Dashboards cannot be scheduled for email delivery or subscribed to . Because the system cannot determine which user's security context should be used when generating a mass automated email, scheduled delivery is disabled.
Dashboard Filters
Administrators can add up to 5 Dashboard Filters , each with up to 50 filter options . Filters allow viewers to slice dashboard data interactively across all components simultaneously (e.g., filtering all charts by StageName , Region , or FiscalYear ).
Folder Sharing & Access Governance
Reports and dashboards use folder sharing to control artifact access; private folders and relevant user permissions also matter. Folder sharing controls access to the analytics artifact, combined with the user's report/dashboard permissions. Object, field, and record access still govern the underlying data; a specified dashboard running user can expose additional aggregate data:
Viewer : The user can open, view, and run reports or dashboards in the folder. They cannot edit or save changes.
Editor : The user can view, edit, add, and delete reports or dashboards within the folder.
Manager : The user can view, edit, delete, and manage folder sharing permissions, including granting folder access to other users, roles, or public groups.
Note
Reports saved in a user's "Private Reports" folder cannot be accessed by anyone else in the company, including system administrators, unless an administrator explicitly logs in as that user or utilizes administrative API migration tools.
Official Source Check
Checked October 19, 2026: Reports and dashboard allocations .