Salesforce Intern

Every Salesforce project starts with a data model, and getting it wrong early is expensive to fix later.

In this task you will set up your own environment and design the structure a real business would run on.

Nothing is supplied to you; you create the org yourself in a few minutes.

Begin by signing up for a free Salesforce Developer Edition account at the official Salesforce developer signup page.

This is free, permanent, and gives you full system administrator rights in your own org.

Record your org's username and the date you created it.

Spend your first session in Setup, locating the Object Manager, the Flow Builder, and the Users page, since you will return to all three repeatedly.

Next, choose one business to model.

A coaching institute, a local gym, a car service centre, a courier operation, or a small clinic all work well.

Write a one-page brief describing what this business sells, who its customers are, what a typical transaction looks like from first enquiry to completion, and what the owner currently struggles to track.

From that brief, design the data model before you build anything.

On paper or in a diagram, list the objects you need, decide which can use standard Salesforce objects such as Account, Contact, Lead, and Opportunity, and which genuinely require a custom object.

For each object, list its fields with their data types, and mark which fields are required.

Then define the relationships between objects, stating for each whether it is a lookup or a master-detail relationship and justifying the choice in one sentence.

Now build it in your org.

Create the custom objects and fields exactly as designed, set up the relationships, and add at least one formula field and one picklist with a controlled set of values.

Create a validation rule that prevents an obviously bad record from being saved, such as a close date in the past or a negative amount, and write down the error message a user would see.

Finally, populate the org with at least fifteen realistic records spread across your objects, entered manually or through the Data Import Wizard that is built into Salesforce.

Invented data is expected here; the point is that the relationships hold together and the records look like something the business would really have.

Submit a PDF containing your business brief, your data model design with the justification for each relationship type, screenshots from Object Manager showing each object and its fields, a screenshot of your validation rule firing, and a short note on the one design decision you were least certain about and the alternative you rejected.

Security in Salesforce is layered, and administrators are judged on getting it exactly right: too tight and people cannot do their jobs, too loose and confidential records leak across teams.

This task is completed entirely inside the free Developer org you created earlier.

Start by writing an access requirement for the business you modelled.

Define at least three distinct kinds of user, for example a sales executive, a team manager, and a support agent.

For each, state in plain language which objects they must read, which they must edit, which they must never see at all, and whose records they should be able to view beyond their own.

Next, build the role hierarchy.

Create roles reflecting the reporting structure of your business and arrange them so that managers sit above the executives who report to them.

Write a short explanation of what the hierarchy does on its own, specifically that it allows people higher up to see records owned by those below them.

Now configure object-level access.

Create a custom profile for each kind of user, or clone an existing one, and set the object permissions for create, read, edit, and delete on every object in your model.

Then set field-level security so that at least one sensitive field, such as a salary, margin, or personal phone number, is hidden from one of your user types.

Then set record-level access.

Open the Sharing Settings and set the organisation-wide default for your main custom object to Private.

Explain in writing what changed the moment you did that.

Then create at least one sharing rule that deliberately opens access back up to a specific group, and state why that exception is justified.

Now prove the configuration actually works, which is the part most people skip.

Create one user for each profile using any email address you control, and use the Login As feature available to administrators to enter the system as each of them in turn.

For each user, attempt one action they should be allowed and one they should be blocked from, and screenshot both outcomes.

Where the result differs from your requirement, fix the configuration and record what you changed.

Finish by writing a half-page note explaining the difference between profile permissions and sharing rules in your own words, and describing one realistic situation in which a user could see a record you did not intend them to see.

Submit your access requirement document, screenshots of the role hierarchy, profile and field-level security settings, the sharing rule, the before-and-after test evidence for each user, and the closing note.

Automation is where an administrator saves an organisation real time, and Flow is the tool Salesforce now expects administrators to use.

Everything here is built with clicks rather than code, in your own free Developer org.

Begin by identifying the manual work worth automating.

Returning to your business, write down three processes a person currently performs by hand, such as assigning a new enquiry to the right team member, sending a follow-up when a record sits untouched, or updating a status field once a related record changes.

For each, record who does it today, how often, and what goes wrong when it is forgotten.

Before building anything, map your chosen process.

Pick the one with the clearest business value and draw its logic step by step: what event starts it, what conditions decide the path, what actions follow, and what the end state looks like.

This map is what you will check your finished flow against.

Now build a record-triggered flow in Flow Builder.

Configure the trigger correctly, deciding whether it should run when a record is created, updated, or both, and whether it should run before or after the save.

State in writing why you chose that configuration, since this choice affects performance and is a standard interview question.

Add entry conditions so the flow only runs when it genuinely applies, then build the actions, including at least one decision element that branches the logic.

Next, build a second, different piece of automation.

A scheduled flow that runs daily over a set of records, or a screen flow that guides a user through entering information in a structured sequence, both qualify.

This ensures you have worked with more than one flow type.

Then test deliberately, including the cases designed to break it.

Create records that should trigger the flow and confirm the outcome.

Then create records that should not trigger it and confirm nothing happened, because a flow firing when it should not is a more common and more damaging error than one that fails to fire.

Use the flow's debug feature to capture what happened internally in at least one run, and screenshot the result.

Finally, document the automation as a working administrator would for whoever maintains it next.

For each flow, record its name, its purpose in one line, its trigger and entry conditions, what it does, and what someone must check before modifying it.

Add a note on the one scenario where your automation would produce an unwanted result and how you would guard against it.

Submit your three-process analysis, the process map, screenshots of both flows in Flow Builder, your trigger configuration reasoning, the positive and negative test evidence with debug output, and the maintenance documentation.

A CRM is only useful if it answers questions, and reporting is the skill that turns stored records into decisions.

This final task uses the org, data, and automation you have already built, and needs nothing beyond your browser.

Start with the questions rather than the tool.

Write down six questions the owner of your business would genuinely ask, such as which service generates the most revenue, how many enquiries went nowhere last month, which team member closes fastest, or where deals are getting stuck.

Vague questions produce vague reports, so make each one specific enough to have a definite answer.

Before building, make sure there is enough data to report on.

Expand your records so that each object holds at least thirty entries spread across different owners, dates, stages, and amounts.

Flat, identical data produces reports that look fine and reveal nothing, so deliberately vary it.

Now build at least four reports, using more than one report type so you are not repeating the same exercise.

Include at least one summary report grouped by a meaningful field, at least one report using a filter that limits it to a relevant time period, and at least one that uses a formula or bucket column to derive something not stored directly in a field.

For each report, note which of your six questions it answers.

Next, assemble a dashboard.

Add at least four components drawn from your reports, choosing the chart type deliberately: a bar chart for comparing categories, a line chart for change over time, a gauge or metric for a single headline number.

Write one line per component explaining why that visualisation suits that question.

Arrange the dashboard so the most important number is where the eye lands first, at the top left.

Then interpret what you built, which is what separates an administrator from a report generator.

Study your own dashboard and write down three things the data actually shows about the business, including at least one that would not have been obvious without the reports.

Where the data looks wrong or surprising, investigate whether it reflects reality or a flaw in how you built the report, and record what you found.

Finally, write a summary of roughly 500 words addressed to the business owner rather than to a technical reviewer.

State what the CRM now tracks, what the dashboard reveals, which single number you would ask them to watch weekly and why, and what you would build next with more time.

Avoid Salesforce jargon entirely, because the ability to explain a system to the person paying for it is the skill being assessed.

Submit your six questions, screenshots of all four reports with their configuration visible, a screenshot of the full dashboard with your reasoning for each component, your interpretation notes, and the owner summary.