Salesforce CRM Analytics Intern

Analysis is only as good as the data beneath it, and most reporting exercises fail because the data is too flat to show anything.

Sign up for a free Developer Edition org.

Choose a business with measurable activity, such as a service company, retailer, or training institute.

Design for reporting specifically.

Decide what questions the business will ask, then work backwards to the fields needed to answer them.

Pay attention to the fields that make grouping possible: dates, owners, categories, stages, and amounts.

A missing category field is what makes an otherwise good dataset unreportable.

Build the objects, fields, and relationships, including at least one formula field and one picklist you intend to group by.

Now generate data with deliberate variation.

Create at least sixty records spread across several months, multiple owners, different categories, and a realistic spread of amounts.

Build in genuine patterns: one category that performs better, one owner who is slower, one month that dipped.

Document the patterns you planted, because later you will check whether your reports actually surface them.

Then validate the dataset.

Build a simple report per object confirming the records exist with the variation intended, and fix anything flat.

Submit the question list, the data model with its reporting justification, the data generation record including planted patterns, and the validation reports.

Work through Salesforce reporting in increasing difficulty, documenting each step.

Build a tabular report listing records with selected columns, then convert it to a summary report grouped by a meaningful field, and record what grouping changed about what you can see.

Now apply filters properly.

Build a report filtered to a relative date range such as the current quarter, and explain why a relative filter is preferable to typed dates.

Then build one using filter logic combining conditions with OR, and verify it returns what you expect by checking the record count manually.

Next, derive values the data does not store.

Build a report with a bucket column grouping values into bands, such as deal sizes or age ranges, and another with a row-level formula calculating something like days open or value per unit.

Then build a custom report type.

Define one covering an object combination the standard types do not offer, including the related object fields, and build a report on it that was impossible before.

Explain what the standard types could not do.

Now check your reports against truth.

Return to the patterns you planted in your data and confirm your reports actually reveal them.

Where a report misses a known pattern, fix the report and record what was wrong.

Finally, build one deliberately misleading report, such as one with a filter hiding bad news, and write what makes it misleading.

Submit all reports with configuration visible, the progression notes, the custom report type justification, the pattern verification, and the misleading report with its critique.

The same data serves different audiences only when presented differently, and this task is about that translation.

Define the audiences.

For an executive, a middle manager, and a frontline team member, write what each decides, how often they look, and how much detail they can act on.

An executive who receives operational detail stops looking entirely.

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

Justify every component by the decision it informs.

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

Build the frontline dashboard showing that person their own work, their queue, and their standing, using dynamic dashboard behaviour or filters where appropriate, and record which mechanism you used.

Now apply layout discipline to each.

Place the most important element top left, and write one line per component explaining why that chart type suits that question.

Replace at least one chart with a different type and explain why the replacement reads better.

Then test comprehension.

Show one dashboard to someone unfamiliar and ask what they conclude.

Where their conclusion differs from the data, the dashboard is at fault; revise it and record the change.

Finally, configure a subscription so the right dashboard reaches its audience without them logging in.

Submit the audience definitions, all three dashboards with component reasoning, the chart replacement rationale, the comprehension test, and the subscription setup.

This task is the analyst's actual output: not the dashboard but the conclusion drawn from it.

Interrogate your own data.

Study your reports and dashboards and write down every pattern you can find, including trends over time, differences between categories or owners, and anything that contradicts what the business would expect.

Separate signal from noise.

For each pattern, assess whether it is large enough and consistent enough to act on, or whether it could be an artefact of your dataset size.

State this honestly for each finding, because an analyst who presents noise as insight loses credibility once.

Investigate the surprises.

Take the two most unexpected findings and dig into the underlying records to determine whether they are real or a reporting error.

Document what you found, including any report you had to correct.

Now write the findings report of roughly 800 words for the business owner.

Open with the three things they most need to know, support each with the number and where it came from, and recommend a specific action per finding.

Use plain language with no Salesforce terminology.

Add the metric critique.

Name the single metric you would ask them to watch weekly and why, then name one metric that looks appealing but you would advise against targeting, explaining how it could be gamed.

Finally, state what you could not determine from this data and what would need to be captured to answer it.

Submit the pattern list with signal assessment, the surprise investigations with any corrections, the findings report, the metric critique, and the data gap statement.