If a dashboard is timing out, the fix is almost never “try a different chart.”
It’s usually filters that are too wide, report types that are doing too much, row formulas that are doing work over and over, or a security mismatch that makes people think the data is “wrong.”
This is the approach I use to get dashboards snappy and keep access honest.
Start with security (or you’ll debug the wrong problem)
Reports respect:
- object perms
- field-level security
- record access (OWD/roles/sharing)
- “View All”/“Modify All” (bypasses sharing)
Diagnostic:
- run as Admin
- run as a normal user
Different counts = access/sharing issue, not filters.
Why reports get slow
1) weak default filters
“All time” datasets are expensive. Prefer:
- last 90 days
- current FY
- this quarter
2) complex report types / cross filters
Cross filters and deep relationships help, but cost. If the metric needs complex logic reliably, consider:
- reporting snapshots
- summary objects (“facts tables”)
3) formulas everywhere
Row-level formulas are easy to overuse. If a metric is stable and high value, compute once (field/automation) rather than at runtime.
Dashboards: reduce load
- limit components (6–10 is enough)
- avoid high-cardinality groupings where possible
- choose “run as viewer” vs “run as user” intentionally
Accidental data exposure patterns
- folder sharing too broad
- “Export Reports” permission assigned widely
- “View All” used as a shortcut
- sensitive fields scattered across unrelated permission sets
Checklist
Performance:
- strong default date filter
- minimal joins/cross filters
- limited row formulas
- dashboard component count reasonable
Security:
- folder sharing least privilege
- export controlled
- tested as normal user