Salesforce Reporting and Dashboard Intern

Reports built from available fields rather than from questions produce output nobody uses.

Sign up for a free Developer Edition org and build a data model with enough variation to analyse, with at least fifty records spread across owners, dates, categories, and amounts.

Write the questions first.

Produce ten specific questions a manager in your business would ask, each precise enough to have one definite answer.

Reject anything vague, since a vague question produces a report nobody can act on.

For each question, plan the report before building it, stating the object, the fields needed, how it should be grouped, what filter applies, and what the answer looks like.

Now build all ten.

Use the report format suiting each question, covering tabular, summary, and matrix, and record why each format fit.

At least one must be a matrix report grouped in both directions, and you should write what that reveals that a summary cannot.

Verify each answer.

For at least four reports, check the result by examining the underlying records manually to confirm the report is telling the truth, because a plausible wrong number is more dangerous than an obviously wrong one.

Then handle the questions you could not answer.

Identify which of your ten the data cannot support, and state what would need to be captured.

Finally, write which report you expect to be used weekly and which you built but nobody will open, with reasoning.

Submit the ten questions, the report plans, all ten built reports with configuration visible, the manual verification, the unanswerable questions, and the usage prediction.

Standard report types cover common cases, and the interesting questions usually fall outside them.

Find the limitation.

Write three questions your data could answer but standard report types cannot reach, such as those spanning an unusual object combination or needing records without related records.

Build custom report types.

Create at least two, defining the primary object, the related objects, and whether the relationship is required or optional.

Make one use the with-or-without option so records lacking a related record still appear, then build the report proving it, since this is how you find the gaps such as customers with no activity.

Add the fields deliberately.

Configure which fields are available and in the default layout, and explain why exposing every field makes a report type harder to use.

Now derive what the data does not store.

Build a report with bucket columns grouping values into meaningful bands and explain your band boundaries.

Build another with a row-level formula calculating something per record, such as days elapsed or value per unit.

Then add a summary formula calculating across a group, such as a percentage of total, and write how it differs from a row-level formula.

Use cross filters.

Build a report filtering on the absence of related records, and state what business question that answers.

Then test the edges.

Confirm your formulas behave correctly when a field is blank or zero, because division by an empty field is a common silent failure.

Submit the three unanswerable questions, both custom report types with configuration, the with-or-without report, the bucket and formula reports with reasoning, the cross filter report, and the edge case testing.

Define the three audiences precisely: an executive, a middle manager, and a frontline team member.

For each, write what they decide, how often they look, how long they will spend, and what level of detail they can act on.

Build the executive dashboard with at most four components, carrying headline numbers and direction of travel rather than breakdowns.

Every component must answer a question the executive acts on, and you should justify each.

Build the manager dashboard with the granularity to manage: performance by person and category, and the exceptions needing attention this week.

Build the frontline dashboard showing that individual their own work and standing, using dynamic dashboards or filters as appropriate, and record which mechanism you used and its limitation.

Apply layout discipline.

For each dashboard, place the most important element where the eye lands first, group related components, and write one line per component explaining why that chart type suits that question.

Then prove a choice.

Take one component, build it as two different chart types, and write which reads better and why, since chart selection is a decision rather than a default.

Test comprehension.

Show each dashboard to someone unfamiliar, ask what they conclude, and where their conclusion diverges from the data treat the dashboard as at fault.

Revise and record what changed.

Finally, write what you deliberately left off the executive dashboard and why restraint improved it.

Submit the audience definitions, all three dashboards with component justifications, the chart comparison, the comprehension tests with revisions, and the restraint note.

Reporting environments decay predictably: hundreds of reports, nobody knowing which are trusted, and numbers that disagree.

Set up delivery.

Configure report and dashboard subscriptions so each audience receives what they need on a schedule, with filters appropriate to the recipient.

Record the schedule per audience and why that frequency, since daily delivery of a weekly metric trains people to ignore it.

Test the delivery.

Confirm a subscription arrives and that the recipient sees data appropriate to their access rather than yours, which is a common and serious reporting leak.

Build the folder structure.

Organise reports into folders with access set per audience, and write the naming convention you chose so a report's purpose is clear from its name alone.

Now establish governance.

Write the rules for your reporting environment covering who may create reports, where personal reports live versus shared ones, how a report becomes official, and when a report gets retired.

Then define the single source of truth for your three most important numbers, stating which report is authoritative and why.

Hunt the contradictions.

Build two reports that should agree but do not, caused by different filters or date fields, then explain the discrepancy and state which is correct.

This is the problem that destroys trust in reporting.

Document the key reports.

For your five most important, record the purpose, the definition of each metric in business terms, the filters applied, and who owns it.

Finally, write the maintenance routine someone would follow monthly.

Submit the subscription configuration with delivery evidence, the folder and naming structure, the governance rules with sources of truth, the contradiction investigation, the report documentation, and the maintenance routine.