BA Academy — self-paced module
By the end of this module, you will be able to:
Recall from Module 1 that developing reports and dashboards, iterating with the client until they meet the business need, is one of the BA's named core activities. Recall from Module 8 that actionable analytics is one of the admin's five core responsibilities. This module is where those responsibilities get their hands dirty.
Reports and dashboards are the platform features that turn stored data into visible answers. Reports group together data that meets criteria you define, such as open opportunities worth over a certain amount. Dashboards visually display information from multiple reports in one place, such as a business's top and lowest performing accounts side by side. Together they are how a business sees its own big picture and makes informed decisions.
When someone asks you to build a report, the request arrives as a question: Which products are my top sellers? Who are my highest-value prospects? Which marketing campaigns have been most successful? How satisfied are my customers? The craft is getting from that question to the right report, and it is a miniature version of everything you learned in Modules 3 and 4.
Here is the canonical example, from Salesforce's own training. Maria is the admin at Ursa Major Solar (the fictional solar-equipment company you have met before). Her CEO, Sita, asks: "Which products are my top sellers?"
An inexperienced builder would open the report builder immediately. Maria instead does discovery in miniature, asking follow-up questions:
Sita's answers become requirements:
And the requirements map to report criteria:
Question, follow-ups, requirements, criteria. That pipeline is this entire module in one table, and it is the same elicitation discipline from Module 3 pointed at analytics. Do not skip the middle steps: the gap between the question someone asks and the report they actually need is where analytics projects quietly fail.
Different people bring different questions. An account executive planning the day wants to know which prospects to contact first. A COO measuring case deflection since launching a self-service community wants a year of case data. A CEO planning next year wants leads by city. Every one of them needs you to translate their question into the report or dashboard that answers it.
Report. In its simplest form, a list of records (opportunities, accounts) meeting criteria you define. But reports go far beyond lists: you can filter, group, and do math on records, and display results graphically as charts.
Report type. The template a report starts from. Choosing a report type selects which records and which fields your report can see. "Opportunities with Products" sees opportunity records joined to their products; "Accounts" sees accounts. If a report cannot find a field you need, the report type is usually why: check it before rebuilding anything. When the standard types fall short, admins can create custom report types.
Dashboard. A page of widgets, each powered by a source report, presenting multiple visualizations side by side.
Folders. Reports and dashboards live in folders, and folders control sharing and organization: who can view, who can edit. Organizing analytics into sensibly named, sensibly shared folders is unglamorous and pays off every single week. Name reports so others can find them, and use descriptions: "Open Opps This Year (by Rep)" beats "Report 47" forever.
The report builder is a drag-and-drop environment. The workflow: from the Reports tab, click New Report, select a report type, and start. Three panels do the work:
Save your report with a clear name and description, choose the right folder, then Run to execute it. The preview shows sample data as you build; refresh it manually or turn on automatic previews.
Choosing the format is choosing what kind of answer the report gives.
The simplest and fastest format: an ordered set of columns with each matching record as a row, like a spreadsheet. Perfect for flat lists: a mailing list, a list of open opportunities for a rep to work through. Limitations: no grouping, and a tabular report can feed a dashboard only if you give it a row limit.
Worked example: for a rep who wants all open opportunities, filter Show Me = All Opportunities, Status = Open, date range as small as practical, and keep the default columns (opportunity name, amount, stage, close date, owner, and so on). Save as "Open Opportunities This Year" and run. Done: a working to-do list.
Summary reports add row grouping, subtotals, and chart support. Group those same opportunities by Stage and you can see counts and totals per stage: structure that answers "how many, of which kind?" questions. When the COO wants closed support cases broken down by priority (high, medium, low), grouping cases by priority in a summary report answers him in one screen.
Summary reports are the workhorses of reporting: most reports end up in this format, and they are excellent dashboard sources.
Matrix reports group by both rows and columns: opportunities by rep (rows) and by quarter (columns), cases by product (rows) and priority (columns). Choose matrix when the question has two dimensions: "who sold what, per quarter?" If you find yourself wanting a spreadsheet pivot table, you want a matrix report.
One selection heuristic: list = tabular; one grouping = summary; two groupings = matrix. Both summary and matrix formats support charts, bucket fields, and formulas; tabular is for flat lists.
Filters are how a report gets specific. Five kinds:
Standard filters. Most objects include them; the common two are Show Me (common ownership groupings: My accounts versus All accounts) and a date filter (a date field plus a range). Practical performance tip: always set the smallest date range you can; reports sifting through all of history run slowly.
Field filters. The general-purpose tool: pick a field, an operator, and a value. "Type equals Customer - Direct." "Amount greater than 50,000." A caution from the source material: the not equals operator can make reports run slowly or time out; use it sparingly and watch performance.
Filter logic. Boolean conditions (AND, OR, NOT) controlling how field filters combine: "(1 AND 2) OR 3." Without filter logic, all field filters apply as AND. Filter logic applies only to field filters, not standard filters. This is where Maria's "Filter logic = 1 AND 2" came from in the worked example.
Cross filters. The power tool: filter a report by a related child object using WITH or WITHOUT conditions: "Accounts WITH Opportunities," "Accounts WITHOUT Cases." Add subfilters on the child object for precision ("Accounts WITH Opportunities where Opportunity Name equals ACME"). The killer use case is exception reporting: finding what is missing. "Customers WITHOUT open renewal opportunities" is a revenue-saving report, and cross filters build it without code or formulas. Remember Module 6: cross filters lean directly on the object relationships in the data model.
Row limits. For tabular reports: cap the rows, pick a sort field and order. "Top 10 accounts by revenue" is a row-limited tabular report, and row limits are what qualify a tabular report to feed a dashboard component.
Filters can also be locked on the report run page, so viewers cannot change them: useful when a report must always answer exactly the same question.
Reports answer questions; dashboards keep the answers visible. A dashboard presents multiple reports side by side as widgets on a single page, each widget fed by one source report (plus rich text and image widgets for labeling and branding).
From the Dashboards tab: New Dashboard, name it, create. Then add widgets (+ Widget) and dashboard-level filters (+ Filter). Click a widget to resize it, delete it, or change its source report; drag to reposition. A responsive grid supports widgets of different sizes in any arrangement.
Choosing widget types:
Source-report constraints worth knowing: joined reports and historical trend reports cannot power dashboard widgets, and tabular sources need row limits.
A worked flow, condensed: the COO asks for a sales-pipeline overview. Build the source report first (Leads grouped by Lead Source, all leads, all time), save it as "Leads by Lead Source," then build a dashboard whose first widget is a chart driven by that report. Add widgets for pipeline by stage, top open deals (row-limited table), and a closed-won metric, and the COO has his overview: four reports, one glance.
Every dashboard runs as somebody: the data shown is the data its running user can see, under all the security you learned in Module 7. A standard dashboard runs as one specified user, showing every viewer the same picture. A dynamic dashboard runs as the logged-in viewer: each person sees the data their own access allows. One "My Team's Pipeline" dynamic dashboard shows each manager their own team, automatically, without building a dashboard per manager.
Dynamic dashboards are the elegant answer whenever the requirement says "each manager should see their own region's numbers": one artifact, personalized by security. Editions limit how many dynamic dashboards an org can have, so they are used deliberately, not by default.
Two lighter options complete the toolkit: add a chart directly to a report itself, and embed report charts on record pages, so (for example) an account page shows that account's open cases as a chart right where users already work. Sometimes the best dashboard is no dashboard: the chart living exactly where the decision gets made.
Pulling the module together into the loop you will actually run on projects:
And one honest caution to close: a report is only as good as the data beneath it (Module 8's data quality lesson) and the security around it (Module 7: reports respect field-level security, and dashboards show what their running user can see). When a report "looks wrong," the cause is usually upstream: the data, the report type, or visibility, in roughly that order.
8 questions. Answer at your own pace, then check the explanation for each.
Nice work. Review any question again using the menu (top right), or move on.