Salesforce Sales Cloud Intern

Sign up for a free Developer Edition org, which includes Sales Cloud functionality in full.

Design the lead process before configuring.

Define what information must be captured for a lead to be workable, what qualification means for your business, and the exact criteria separating a lead worth pursuing from one worth discarding.

Vague qualification is why sales teams waste time.

Configure the Lead object.

Set up lead statuses reflecting your qualification stages, add the fields your process needs, and build a validation rule preventing a lead advancing without the information that stage requires.

Set up capture.

Configure Web-to-Lead, generate the form, and submit at least five test leads through it, confirming they arrive with the right field values and owner.

Now automate assignment.

Build lead assignment rules routing leads to different owners based on a meaningful criterion such as region or product interest, and prove it by submitting leads that should route differently.

Then handle conversion.

Convert qualified leads and document exactly what Salesforce creates, which records are linked, and what happens to the original lead record.

Convert one lead to an existing account rather than a new one and record the difference.

Finally, build a report showing conversion rate by lead source and write what it tells you about where to spend effort.

Submit the process design, configuration screenshots, the five captured leads, assignment rule evidence, conversion documentation, and the conversion rate report.

Opportunity stages are where most Sales Cloud implementations quietly go wrong, because stages defined by internal activity rather than customer commitment produce forecasts nobody trusts.

Design your stages.

Define six to eight stages for your business, and for each write the objective evidence required to enter it, expressed as something the customer has done rather than something your team has done.

Assign a probability to each and justify it.

Configure them in your org, setting the stage picklist, the probability per stage, and the forecast category.

Now enforce the definition.

Build validation rules requiring the evidence fields for each stage before an opportunity advances, and configure Path with guidance text telling the user what is required at each step.

Screenshot a validation rule blocking an unqualified advance.

Create pipeline data.

Build at least thirty opportunities spread across stages, owners, amounts, and close dates, including some overdue and some closed lost, since a pipeline of only healthy deals teaches nothing.

Then analyse it.

Build reports showing pipeline by stage, deals slipping past their close date, and win rate by owner.

Identify from your own data where deals are getting stuck.

Finally, write a note on the gaming risk: explain how a sales team could make these numbers look good without selling more, and what you would monitor to catch it.

Submit the stage definitions with evidence requirements, configuration screenshots, validation evidence, the pipeline data, the three reports, your stuck-deal finding, and the gaming note.

Define what your business sells.

List at least eight products or services with their standard prices, and note any that are sold in different configurations or tiers.

Configure Products in your org, creating each with its code and description.

Then set up the standard price book and at least one custom price book representing different pricing, such as a corporate rate or seasonal discount, and explain in writing when each applies.

Attach products to opportunities.

Add line items to at least ten of your opportunities, with varying quantities and some discounted, and confirm the opportunity amount reflects the line items rather than a manually typed figure, since manual amounts are how revenue reporting becomes fiction.

Now build quoting.

Enable Quotes, create quotes from opportunities, add line items, and generate the quote document.

Produce one quote with a discount and record how it appears.

Then control discounting.

Build a validation rule or approval requirement preventing a discount beyond a set threshold without approval, and prove it by attempting an excessive discount.

Finally, report on it.

Build a report showing revenue by product and another showing average discount by owner, then write what the second report would tell a sales manager.

Submit the product list, price book configuration with its usage rules, line item evidence, the generated quotes, the discount control evidence, and both reports with your interpretation.

Sales processes fail on follow-up rather than strategy, so automate the parts people forget.

Identify the gaps.

From your pipeline, find where deals stall: no activity logged for weeks, close dates passed without update, new leads untouched.

Write down three specific failures worth automating.

Build the automation in Flow.

Create automation that reacts to an opportunity sitting untouched past a threshold, another that handles a close date passing without a stage change, and a third of your choice.

Use a scheduled flow for at least one, since staleness is only detectable on a schedule.

Test both directions.

Prove each automation fires when it should and, more importantly, does not fire when it should not.

Capture debug output for one run.

Now build the manager dashboard.

Create at least six components answering what a sales manager needs on a Monday morning: what is closing this month, what slipped, who is behind, where the pipeline is thin, and which deals need their attention today.

Choose each chart type deliberately and justify it in one line.

Then interpret your own dashboard.

Write three findings your data actually shows, including one that would not have been obvious without it, and investigate anything that looks wrong to determine whether it is real or a reporting flaw.

Finally, write a half page for the sales manager stating which single number to watch weekly and why.

Submit the gap analysis, the three flows with test evidence, the dashboard screenshot with component reasoning, your findings, and the manager note.