Salesforce Reports, Dashboards, and Formulas

The mental model: question, data, and calculation grain

A reports question is rarely just about "making a report." It usually tests whether you can translate a business question into a data structure. First identify what the person wants to know: a list of records, a subtotal by group, a comparison across two dimensions, the existence of related records, or an executive visualization. Then decide which data the report needs and at what level the calculation should happen.

The common mistake is jumping straight to dashboards or formulas. A dashboard does not fix a poorly built report. An object formula is not always necessary if the calculation only lives inside one report. A bucket field can group values for analysis without creating new fields. And a cross filter can answer "with" or "without" related-record questions without inventing a complicated formula.

Practical rule: report type decides which data you can use; format decides how it is organized; filters decide what enters; formulas and buckets decide how it is calculated or grouped.

Report types and relationships

The report type is the entry point. It defines the primary object, available related objects, and whether the report shows records with or without relationships. If you choose the wrong report type, you can spend a long time searching for fields that will never appear. That is why a question mentioning Accounts with Opportunities, Cases with Activities, or Contacts without Campaign History is not only about filters; it may be testing data relationships in the report type.

Standard report types cover many common scenarios, but custom report types help when you need a specific combination of objects or fields. On the exam, custom report type is a candidate when users cannot create a report with the relationship or fields they need using standard types. Do not choose it by habit: first confirm that the need really does not fit an existing report type.

Also remember security. Access to a report folder does not mean users see every record in the report. Results respect the user's permissions, field-level security, and sharing, except for specific dashboard running-user behavior. This distinction appears in questions where someone can open a report but cannot see certain records or fields.

Report formats

Tabular is the simplest format: a list of rows and columns. It is good for exports, operational lists, and details without grouping. If a question asks for a "list of all contacts missing email", tabular may be enough. But if it needs charts, subtotals, or comparisons, another format is probably required.

Summary groups rows by one dimension and allows subtotals. It is useful for questions such as opportunities by stage, cases by priority, or revenue by owner. Matrix groups by rows and columns, ideal for comparing two dimensions at once, such as region by quarter or product by stage. Joined combines report blocks to view related data in separate sections, although it is not always the first Administrator answer when summary or matrix solves the case.

In exam questions, look for words like group by, summarize, compare across rows and columns, or multiple blocks. One grouping dimension usually points to summary. Two dimensions, one in rows and one in columns, point to matrix. A flat list points to tabular. Multiple views in blocks point to joined.

Filters, filter logic, and cross filters

Filters reduce the set of records. They can be standard filters, field filters, relative date filters, or filter logic when you need to combine conditions with AND and OR. If the user says "open opportunities this quarter for enterprise or strategic accounts", the important part may be correct logic, not a different format.

Cross filters answer questions about related-record existence: Accounts with Opportunities, Accounts without Opportunities, Cases with Activities, or Contacts without Campaigns. They are important for the exam because they avoid false solutions such as formulas to count children or impossible filters on fields that do not exist on the primary object.

If the question says "with at least one related record" or "without related records", think cross filter. If it says "filter by field values", think normal filters. If it says "several combined conditions", think filter logic. A strong answer keeps the criterion inside the report when there is no need to change the data model.

Row-level formulas, summary formulas, and bucket fields

Row-level formulas calculate a value for each row in the report. They help answer questions such as "how many days was each case open" or "flag each opportunity by margin". The result lives in the report and is evaluated per displayed record. It is not the same as an object formula field, which is reusable configuration across many parts of Salesforce.

Summary formulas calculate over groups, subtotals, or the report total. They are useful for percentages, comparisons between aggregates, and metrics such as win rate by region. If the question talks about calculation by group, subtotal, percentage of total, or comparison between periods, a summary formula is a better candidate than a row-level formula.

Bucket fields group values inside a report without creating a new object field. For example, grouping Amount into Small, Medium, and Large, or grouping industries into segments. If the grouping is needed only for one report, a bucket field can be cleaner than creating a custom field. If it is needed in many automations, layouts, or integrations, a real field may make more sense.

Dashboards, running user, and subscriptions

A dashboard displays visual components based on source reports. It does not replace the report; it depends on it. If a component shows incorrect data, first review the source report, filters, groupings, and security. Dashboard filters let the viewer change a shared dimension, such as region, team, or period, without maintaining many versions of the same dashboard.

The running user defines whose data access a static dashboard uses. This can cause viewers to see data according to the running user's access, not necessarily their own. Dynamic dashboards, when available, run as the logged-in viewer. In security questions, this matters: executives who need to see only their own territory may point to dynamic dashboard; a central executive view may point to a specific running user.

Subscriptions send reports or dashboards by email on a schedule. Report subscriptions can include conditions, for example sending only if open cases exceed a certain number. If the question says notify when a metric crosses a threshold, subscribe to the report with conditions is a candidate. If it only asks for an interactive view, do not confuse subscription with dashboard filter.

Common mistakes when studying analytics

The first mistake is confusing calculation grain. If the result should appear on every row, think row-level. If the result is calculated by group or total, think summary formula. If the need is grouping values for easier reading, think bucket. If the formula is needed outside the report, evaluate an object formula field.

The second mistake is using dashboards to solve data questions. A dashboard visualizes; it does not create missing relationships or fix bad filters. The third mistake is forgetting security: folder sharing grants access to the artifact, but visible data depends on permissions, sharing, and running user. The fourth mistake is using reports when the question really describes automation, validation, or permanent storage.

Read words like row, group, total, dashboard viewer, running user, without related records, conditional email, filter by region, and compare quarter by product. Those words almost always reveal the correct tool.

Quick decision checklist:

Does the question ask for a list, grouping, matrix, blocks, or visualization?
Does the report type contain the required objects and relationships?
Is the condition a normal filter, filter logic, or cross filter?
Is the calculation per row, per group, or only a visual grouping?
Should the dashboard respect the viewer or a defined running user?

Official resources and practice

To study this topic, build the same scenario several ways. Create a tabular list, then a summary grouping, then a matrix by two dimensions, and finally a dashboard with a filter. Also practice a row-level formula, a summary formula, and a bucket field. The goal is to recognize the correct grain before reading the options.

BlueForce is not affiliated with Salesforce. This guide is original editorial content based on study experience, public objectives, and official resources.