Salesforce Security and Access Intern

Sign up for a free Developer Edition org and build a data model with at least three objects, including fields holding genuinely sensitive information such as margin, salary, or personal contact details.

Understand the layers before configuring.

Write an explanation of how Salesforce decides whether a user can see a given field on a given record, naming each layer in order and what it controls.

Most access mistakes come from configuring one layer while assuming another.

Define the requirement.

For at least four user types, state which objects they need and at what permission level, and which specific fields must be hidden from each.

Now configure object permissions.

Create a profile per user type and set create, read, edit, and delete deliberately per object, granting the minimum the role requires.

Configure field-level security, hiding your sensitive fields from the user types that must not see them, and setting at least one field to read-only for one type.

Verify from the seat.

Create a user per profile and use Login As for each.

Confirm the objects they should reach are reachable and those they should not are absent.

Confirm hidden fields are invisible on the record, and then check the quieter routes: whether the field appears in a report, a list view, or a related list, since these are the common leaks.

Fix anything that leaked and retest.

Finally, write the layer that surprised you and why.

Submit the layer explanation, the access requirement, profile and field configuration, per-user verification including report and list view checks, the leak fixes, and the surprise note.

Most orgs accumulate dozens of nearly identical profiles because cloning is the easy path, and this task shows why that becomes unmaintainable.

Create the problem.

Starting from your profiles, add three new user variations differing from an existing type in only one or two permissions, and implement them by cloning profiles.

Now count the profiles and write what happens when a permission must change for everyone.

Demonstrate the cost.

Make one permission change that must apply to all profiles, record how many places you had to change it, and note the chance of missing one.

Now rebuild properly.

Design an access model with a small number of base profiles carrying the minimum everyone needs, plus permission sets granting additional capability.

Write which permissions belong in a profile and which belong in a set, with your reasoning.

Implement it.

Create the base profiles and the permission sets, then assign sets to users to reproduce every variation you built by cloning.

Verify each user still has exactly the access intended, using Login As and testing both permitted and forbidden actions.

Then repeat the change.

Make the same org-wide permission change in the new model, record how many places you changed it, and compare with the cloned approach.

Use permission set groups if available, combining sets for a common role, and write what that adds.

Finally, write the migration note: how you would move an existing org from many profiles to this model without interrupting users.

Submit the cloned profile approach with its change cost, the redesigned model with reasoning, the implementation, per-user verification, the change comparison, the group work, and the migration note.

Record level access is the hardest layer because its behaviour emerges from several settings interacting.

Set up the scenario.

Build records owned by different users across different teams, so that a visibility error would be a genuine problem rather than a theoretical one.

Start from closed.

Set the organisation-wide default for your main object to Private and document what every user can see at that moment, which should be only their own records.

Confirm this by logging in as two users.

Now open access deliberately, one mechanism at a time, documenting the effect of each.

Use the role hierarchy first.

Confirm a manager above a user can now see that user's records, and write precisely why, since hierarchy access is automatic and frequently forgotten when auditing.

Add a sharing rule granting a group access to records matching a criterion.

Verify the intended users gained access and, importantly, that nobody else did.

Use manual sharing on a single record and write when this is appropriate and why it does not scale.

Then test the boundary thoroughly.

For each user, attempt to reach a record they should not see by direct URL, through a report, and through a list view.

Screenshot each denial.

Find the over-grant.

Audit your own configuration for any user who can see more than intended, identify which mechanism granted it, and tighten it.

Finally, write how a new record becomes visible to the right people, step by step through every layer.

Submit the scenario, the private baseline with verification, each mechanism with its documented effect and tests, the boundary denials, the over-grant finding and fix, and the visibility walkthrough.

Access configuration drifts, and the audit is how a security-minded administrator catches it.

Build the access inventory.

For every user in your org, document every object they can reach, at what permission, which fields are hidden, and which records they can see.

Build this from the configuration rather than from memory.

Now find the excess.

For each user, compare what they can do against what their role genuinely requires, and flag every permission that is broader than necessary.

Pay particular attention to delete permissions, modify-all and view-all settings, and administrative permissions granted casually.

Check the dangerous permissions specifically.

Identify who can export data, who can modify metadata, and who holds the administrator profile, then write why each of these matters more than ordinary object access.

Audit the trail.

Open the Setup Audit Trail, review the changes recorded, and write what it would and would not tell you after a security incident.

Test the worst case.

Pick your most privileged non-administrator user and establish exactly what damage they could do, whether that is exporting the customer list, deleting records in bulk, or changing configuration.

State what controls limit them.

Then remediate.

Apply least privilege to at least five findings, retest each affected user to confirm they can still do their job, and record what you removed.

Write the review routine: what someone should check quarterly, in what order, and what evidence they should keep.

Finally, write the single most concerning thing you found in your own configuration and how it got there.

Submit the access inventory, the excess permission findings, the dangerous permission analysis, the audit trail assessment, the worst case analysis, the remediation with retests, the review routine, and the significant finding.