Reports And Dashboards Fundamentals

Reports and Dashboards Fundamentals

Use this skill when designing or explaining Salesforce Reports and Dashboards from the ground up — choosing the right report type, structuring filters and groupings, configuring dashboard components, setting up dynamic dashboards, and distributing results via subscriptions or folder sharing. Activate when a practitioner needs to understand how the platform works, not just fix a broken report.

Before Starting

Gather this context before working in this domain:

Core Concepts

1. Report Types

A report type is the schema that defines which objects and fields are available in a report. Every report is built on exactly one report type.

Standard report types ship with Salesforce and cover common object pairs (Accounts with Contacts, Opportunities with Products, Cases with Solutions, etc.). They use a left-outer join by default — parent records appear even when no related child records exist.

Custom report types (CRTs) are created by admins when no standard type covers the required object combination, or when a standard type exposes the wrong join semantics. A CRT defines:

• A primary object (always required)
• Up to 3 related objects in a chain, each configured as "must have" (inner join) or "may or may not have" (outer join)
• A field layout — which fields appear and in what order in the report builder

Critical CRT limits: maximum 4 objects in a single CRT; maximum 1,000 fields in the field layout.

Join semantics matter: if a CRT leg is set to "must have related records," any parent that has no child of that type is excluded from report results. This is the single most common cause of unexpectedly missing rows.

2. Report Formats

Salesforce offers four report formats:

Tabular reports cannot be used as dashboard source reports directly unless they have a row limit applied. Summary and Matrix reports are the standard dashboard source formats.

Joined reports have strict limits: maximum 5 blocks, 100 columns per block, 10 custom summary formulas per block (50 per report), and 10 cross-block formulas. Bucketed fields, cross filters, and conditional highlighting are unavailable inside a joined report entirely. On a dashboard you can add a joined report's chart as a widget but not the full report, and you cannot add a filter to a dashboard whose widgets are all joined reports.

3. Filters, Bucket Fields, and Summary Formulas

4. Dashboards and Dynamic Dashboards

A dashboard is a visual display of up to 20 source reports shown as components (charts, metrics, tables, gauges, funnels).

Common Patterns

Pattern 1: Summary Report as a Dashboard Metric Source

When to use: An executive dashboard needs KPIs — total pipeline value, number of open cases, win rate this quarter.

How it works:

1. Create a Summary report on the target object (e.g., Opportunities).
2. Group by Close Date (monthly) or Stage.
3. Add summary fields: SUM(Amount), COUNT(Id).
4. Add a Summary Formula for Win Rate if needed.
5. Apply a relative date filter ("Current FQ" or "This Quarter") so the report stays current without manual updates.
6. In the dashboard, add a Metric component pointing to this report, selecting the summary field as the value.

Why not tabular: Tabular reports cannot drive Metric or Chart dashboard components without a row limit. They lose aggregation — each row is a raw record, not a grouped total.

Pattern 2: Cross-Filter for Negative Conditions

When to use: Finding records that lack a related child — "Accounts with no activity in 60 days," "Contacts without open cases," "Opportunities with no products."

How it works:

1. Start a Summary report on the parent object (e.g., Accounts).
2. Add a Cross-Filter: "Accounts WITHOUT Activities."
3. Optionally add a sub-filter on the cross-filter: Activity Date > LAST 60 DAYS.
4. Group by Account Owner to surface ownership for follow-up.

Why not a formula field: Formula fields cannot reference child record existence without a roll-up summary field on the parent, which requires a master-detail relationship. Cross-filters work on any lookup relationship.

Pattern 3: Custom Report Type for Multi-Object Reporting

When to use: You need columns from three or more related objects, or the standard report type uses the wrong join direction.

How it works:

1. Go to Setup > Report Types > New Custom Report Type.
2. Set Primary Object (e.g., Accounts).
3. Add related objects in sequence: Opportunities (may or may not have), then Opportunity Products (may or may not have).
4. In the Field Layout, add the specific fields needed from each object. Remove noise fields.
5. Deploy the CRT (it takes ~24 hours to appear for end users after initial creation in some orgs).
6. Build the report on this CRT.

Why not standard types: Standard types expose a fixed field set and fixed join semantics. A CRT gives control over both.

Decision Guidance

Recommended Workflow

1. Define the business question — translate the stakeholder ask into: primary object, required fields, grouping dimension, metric (count/sum/formula), and date range. Write it out before touching the UI.
2. Select the report type — use a standard report type if it covers the required objects and join semantics. Create a Custom Report Type only when a standard type cannot provide the needed field set or join behavior.
3. Build the report — apply filters (use relative date ranges, not hard-coded dates), add groupings, add columns, add bucket fields or summary formulas as needed. Preview with real data before saving.
4. Validate results — verify row counts against a known control (SOQL query or list view). Check that filters are not inadvertently excluding records. If counts are off, check CRT join semantics and sharing access before changing filters.
5. Design the dashboard — identify 3–5 key components. Match each component type to its purpose (Metric for KPIs, Bar/Column for comparisons, Line for trends, Gauge for quota progress). Set the running user configuration (static vs dynamic).
6. Configure access and delivery — assign the report and dashboard to a shared folder with appropriate view/edit permissions. If scheduled delivery is needed, set up a Report Subscription (not a dashboard subscription). Confirm subscription recipients are current employees.
7. Document and govern — add a description to the report and dashboard. Record the intended audience, data owner, and refresh cadence. Move reports from private folders to shared folders immediately.

Review Checklist

Run through these before marking work complete:

• Report type (standard vs custom) is the minimum required to answer the business question — no over-engineering
• All date filters use relative ranges ("This Quarter," "Last 30 Days") rather than hard-coded dates
• Groupings produce meaningful subtotals — not a grouping on a high-cardinality field like Email
• Dashboard running user is set to "Run as logged-in user" unless a static view has been explicitly approved
• Dashboard filters tested against all components — confirm which components are and are not affected
• Report and dashboard are in a shared folder, not a private folder
• Report subscriptions are addressed to named, currently active recipients, and each subscription's running user is confirmed (it defaults to whoever created the subscription, not the report owner)
• CRT join semantics verified — "may or may not have" vs "must have" matches the business intent
• Row and block limits confirmed — not approaching 2,000 rows in dashboard tables, not exceeding 5 blocks in joined reports
• No dashboard has more than 20 source report components

Salesforce-Specific Gotchas

1. Tabular reports cannot drive most dashboard components without a row limit — Tabular reports return raw rows. A Metric or Chart component requires an aggregated value. If you drop a tabular report as a dashboard source, it will either error or only display as a table. Set a row limit and sort to enable tabular use in dashboards, or convert to a Summary report.

2. CRT field layout is not the same as field visibility — Adding a field to a CRT's field layout makes it available in the report builder, but field-level security still controls whether individual users can see the field's values. A user who cannot read the field in the UI cannot see it in a report either.

3. Joined report blocks are independent — they do not join on a common key — Blocks in a joined report sit side by side but do not perform a SQL-style JOIN on a shared ID. Each block is its own report with its own filters. If you need a true comparison of matched records, use a Summary or Matrix report on a CRT that includes both objects.

4. Summary formulas can reference PARENTGROUPVAL and PREVGROUPVAL — but only in the correct context — PREVGROUPVAL returns the value from the previous grouping level (e.g., prior month). PARENTGROUPVAL returns the value from the next-higher grouping level (e.g., the region total when you are viewing a territory row). These functions are only available in Matrix and Summary reports, and they require the referenced grouping level to exist in the report.

5. Dynamic dashboards cannot be subscribed to or scheduled — A dynamic dashboard (run as logged-in user) refreshes on demand only. You cannot set a nightly refresh schedule or send a subscription email from a dynamic dashboard. If stakeholders need scheduled delivery, build a separate static report subscription alongside the dynamic dashboard.

Output Artifacts

Related Skills

• admin/reports-and-dashboards — Use for troubleshooting missing or incorrect data in existing reports, diagnosing sharing model impact, and auditing report governance. Use this fundamentals skill for design and first-time build questions.
• admin/sharing-and-visibility — Use when report results diverge from expectations because of record-level sharing rules, role hierarchy, or manual shares. The report is functioning correctly — the access model is the issue.
• admin/permission-sets-vs-profiles — Use when users cannot open a report folder or see specific fields in a report due to object or field permissions. Not for report filter or chart configuration questions.
• admin/einstein-analytics-basics — Use when operational Salesforce Reports and Dashboards are insufficient and CRM Analytics (Einstein Analytics) is being evaluated. NOT for standard reports and dashboards.