1. Start With the Question, Not the Data
Before opening Report Builder, write the question in one sentence: “What’s my team’s close rate by source this quarter?” If you can’t state the question, you can’t build the right report.
The question determines the report type, the filters, the groupings, and the summary measures. Build backwards from that.
2. Pick the Right Report Type
The Report Type is the foundation. It defines:
- Which objects are included.
- The relationship between them (with or without related records).
- Which fields are available.
“Opportunities” (without Contact Roles) and “Opportunities with Contact Roles” are different report types. Picking wrong means the report is incomplete or shows duplicated rows.
Custom Report Types let you define exactly the objects and relationships you need. For recurring report needs, build one.
3. Use Row-Level Formulas Instead of Cross-Filter Hacks
Row-level formulas (introduced as GA a while back) compute per-row values — “Revenue per Deal” = Amount / TotalLineItems. Before, you’d build it as a formula field on the object or as a cross-filter trick.
Row-level formulas live in the report, don’t clutter the object, and can be adjusted by report viewers.
4. Bucket Fields for Categorization
Bucket columns categorize records on the fly — “Deal Size” = Small / Medium / Large based on Amount ranges. No custom field needed.
Buckets are saved with the report. Reusable across multiple buckets by creating similar reports, or persistent by promoting the logic to a formula field on the object.
5. Use Summary Formulas for Calculated Summaries
Beyond sum/avg/count, summary formulas compute across groupings: “Win Rate” = Won Deals / Total Deals. Appears at the group level, summary level, and grand total.
The key idea: the formula evaluates at each grouping level. Check that the formula behaves correctly at every level — grand total behavior can surprise.
6. Chart First, Table Second
Every report should have a clear chart that tells the story. The underlying table is the evidence.
When building, start with the visualization. If the chart shows what the question asked, move on. If not, reconsider groupings and measures.
7. Dashboards Should Answer One Purpose
A dashboard titled “Sales Dashboard” is doing too much. “Q4 Sales Performance” is focused.
Each dashboard:
- Answers one purpose (track Q4 performance, monitor this week’s cases, assess pipeline health).
- Uses 4–8 components — more becomes hard to scan.
- Has a clear top-row headline metric.
Users who want different views need different dashboards, not a single kitchen-sink one.
8. Use Dashboard Filters for Reuse
A single dashboard with a region filter can replace five region-specific dashboards. Users filter to their region; the same charts re-render.
Dashboard filters apply to components built on filterable source reports. Design source reports to accept filters (don’t hardcode region in the report).
9. Schedule Dashboard Refresh Thoughtfully
Dashboards refresh on demand (by user) or on schedule (daily/weekly). Scheduled refreshes load to a specific running user’s view.
- For dashboards with role-scoped data (running user is the viewer), schedule against each persona.
- For static summary dashboards, one scheduled refresh overnight is enough.
- Overlapping scheduled refreshes can hit limits — space them out.
10. Lightning Tables for Data-Heavy Components
The Lightning Table component lets users sort, filter, and paginate inline. Better than a static chart when the audience wants to interact.
Use for: opportunity lists, case lists, operational queues. Don’t use for: executive summary metrics (use a KPI metric component).
11. Historical Reporting via Reporting Snapshots
For trend analysis over time, Reporting Snapshots capture a report’s rows into a custom object on a schedule. Report over the snapshot records to see how metrics evolve.
- Set up in Setup → Reporting Snapshots.
- Define source report, target custom object, field mapping, schedule.
- Grows over time — archive old snapshots to manage storage.
12. Sharing Reports Without Chaos
Report folders are the sharing unit. Users get access to a folder, not to individual reports. Structure folders intentionally:
- Public folders for org-wide reports.
- Role-based folders for team-specific reports.
- Personal folder for user scratch work.
- Subscription folders for auto-emailed reports.
Name folders clearly and assign folder-level sharing. Reports inside the folder inherit.
Bonus: Debugging Wrong Numbers
When a report’s numbers don’t match a known source-of-truth:
- Re-check the report type. Are related records included that shouldn’t be? (Joined duplicates are a classic cause.)
- Inspect filter logic. AND/OR precedence can produce unintended filter sets.
- Validate groupings. Sums at each level should be consistent; if the grand total != sum of groups, group definitions aren’t exhaustive.
- Check sharing. A report looks different when run by a user without access to some underlying records.
Common Mistakes
Report explosion. An org with 4,000 reports — most stale — is a signal of no governance. Periodically audit and archive.
Over-filtering. 15 filter conditions hide what’s actually being reported. Simplify.
Dashboards that don’t answer the stated question. Add, don’t remove — dashboards creep. Discipline.
Ignoring performance. Reports with 50,000+ rows, complex joins, and many filters slow down. Add selective filters.
No data refresh clarity. Users need to know when a dashboard last refreshed. Show the refresh timestamp in the dashboard title or header.
Frequently Asked Questions
Is there a report row limit?
Yes — roughly 2,000 rows in the standard report preview, 2,000 in export (CSV without using Analytics Data Export). For larger exports, use CRM Analytics or Data Loader.
Can I email reports to users?
Yes — subscribe users to reports to receive scheduled emails. Dashboards support similar subscription.
Are reports packageable?
Yes — reports and folders are metadata and deploy via change sets, SFDX, or packages.
What about external BI tools?
Reports are for in-Salesforce consumption. For broader BI needs, use CRM Analytics or Tableau.