Salesforce Administrator Intern

Sign up for a free Salesforce Developer Edition account at the official Salesforce developer signup page.

It is free, permanent, and gives you full system administrator rights in your own org, so nothing needs to be supplied to you.

Spend your first session exploring Setup rather than changing anything.

Locate Object Manager, Users, Profiles, Permission Sets, Sharing Settings, Flow Builder, and the Setup Audit Trail.

Record the exact navigation path to each one, because knowing where things live is the difference between a five minute change and an hour of searching.

Now audit the org as delivered.

Document how many standard objects exist, which ones are enabled, what profiles ship by default, what your own user's profile and role are, and what the organisation-wide defaults are set to before you touch them.

Capture a screenshot of each finding.

Next, write an orientation guide for a new administrator joining this org.

Explain in plain language what the org currently contains, what a profile controls versus what a role controls, and the three screens a new admin will use most.

Keep it under two pages, because a guide nobody reads has no value.

Finally, make one small deliberate change, such as adding a custom field to Account, then open the Setup Audit Trail and find your own change in it.

Write a short note explaining why this log matters when something breaks and nobody admits to changing anything.

Submit the navigation reference, the audit with screenshots, the orientation guide, and the audit trail note.

Choose one business to model: a coaching institute, gym, car service centre, courier operation, or small clinic all work well.

Write a one page brief covering what it sells, who its customers are, what a transaction looks like from first enquiry to completion, and what the owner struggles to track today.

Design the data model before building anything.

List the objects you need, decide which can use standard objects such as Account, Contact, Lead, and Opportunity, and which genuinely need a custom object.

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

Then define each relationship, stating whether it is lookup or master-detail and justifying that choice in one sentence, since this decision affects deletion behaviour and reporting later.

Build it in your org exactly as designed.

Include at least one formula field and one picklist with a controlled value set.

Add a validation rule preventing an obviously bad record, such as a past close date or negative amount, and record the error message a user would see.

Populate the org with at least twenty realistic records across your objects, entered manually or through the built-in Data Import Wizard.

Invented data is expected; what matters is that relationships hold and records resemble something the business would really have.

Submit the business brief, the data model design with relationship justifications, Object Manager screenshots of every object and field, a screenshot of the validation rule firing, and a note on the design decision you were least sure about and the alternative you rejected.

Write an access requirement for your business.

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

For each, state which objects they must read, which they must edit, which they must never see, and whose records they should see beyond their own.

Build the role hierarchy so managers sit above those reporting to them.

Explain in writing what the hierarchy achieves on its own, specifically that it lets people higher up see records owned by those below.

Configure object-level access with a custom profile per user type, setting create, read, edit, and delete on every object.

Then use field-level security to hide at least one sensitive field, such as a margin or personal phone number, from one user type.

Set the organisation-wide default for your main custom object to Private and write down what changed the instant you did.

Then add one sharing rule that deliberately opens access back up to a specific group, and justify that exception.

Now prove it works, which is the step most people skip.

Create one user per profile using any email address you control, then use Login As to enter the system as each.

For every user, attempt one action they should be allowed and one they should be blocked from, screenshotting both.

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

Submit the access requirement, screenshots of the hierarchy, profiles, and field-level security, the sharing rule, before-and-after test evidence per user, and a half page note on one situation where a user could still see a record you did not intend.

Administrators work from a queue of requests, and the skill is judging each one before building it.

Write five change requests as a business user would phrase them, vaguely and without technical detail.

Examples: we need to know which staff member handled each enquiry, the team keeps forgetting to follow up, management wants a weekly number, we need to stop people entering wrong dates, and support should not see pricing.

For each request, write a short assessment before touching the org.

State what the user actually needs as opposed to what they asked for, which is frequently different.

Identify the configuration involved, what else it could affect, and whether it is genuinely a five minute change or something larger.

Now implement all five in your org.

Keep each change small and verifiable.

Screenshot the configuration for each.

Then test each change from the affected user's perspective using Login As, confirming the request is genuinely satisfied rather than technically implemented.

For each change, write a rollback note explaining exactly how to undo it, since an administrator who cannot reverse a change should not be making it in production.

Finally, write a short reflection identifying which of the five requests you would have pushed back on and what you would have proposed instead.

Submit the five requests, your assessments, implementation screenshots, test evidence, rollback notes, and the reflection.