Salesforce Experience Cloud Intern

Sign up for a free Developer Edition org, which includes Experience Cloud sites.

Plan before building.

Define who the external users are, whether customers, partners, or applicants, what they need to do without calling anyone, what data they must see, and critically what data exists nearby that they must never see.

Write this last list first, because it is the one that matters.

Design the user journey.

Map what an external user does from arrival through completing their task, and identify the point they would give up and phone instead.

Enable Experience Cloud in Setup and create a site, recording the template you chose and why.

Build the basic structure: a landing page, navigation, and at least two content pages.

Keep it minimal, since the configuration beneath matters more than the appearance.

Configure the site basics including name, URL, and whether it allows self-registration or invitation only, with your reasoning for that choice.

Publish the site and confirm it loads in a browser where you are not logged in as an administrator, which is the only way to see what an external visitor sees.

Then document the exposure.

List everything now reachable from outside your org and confirm each item is intended.

Submit the user and data plan including the must-not-see list, the journey map, site configuration screenshots, the published site viewed as an outsider, and the exposure documentation.

This is where portals leak, and getting it right requires understanding that external access is a separate layer from internal.

Build the data model the portal serves, with records belonging to different external customers so that one user seeing another's data would be a genuine breach.

Create the external user structure.

Set up accounts and contacts representing external organisations and people, then enable at least two contacts as community users with the appropriate licence available in your Developer org.

Configure the profile for external users, setting object and field permissions to the minimum needed.

Start from denial and grant only what the journey requires, which is the opposite of how most portals get built.

Set the sharing model.

Configure organisation-wide defaults for the objects involved, then use sharing sets or sharing rules to give each external user access to their own records only.

Write how your mechanism decides which records a given user can see.

Now test the boundary.

Log in as each external user and confirm they see their own records.

Then attempt to reach another customer's record by direct URL and by any list view or report available, and confirm each attempt fails.

Screenshot every denial, because a portal is only secure once you have tried to break it.

Test the guest user separately.

Determine what an unauthenticated visitor can reach and tighten anything unintended.

Finally, write the leak you nearly shipped and how you caught it.

Submit the data model, external user setup, profile configuration, the sharing model with its logic, the boundary tests with denial evidence, guest user findings, and the near-miss note.

A portal only reduces workload if people complete tasks without help.

Define the self-service tasks.

Choose three things an external user should accomplish alone, such as submitting a request, checking its status, updating their details, or finding an answer to a common question.

Build submission.

Configure a way for external users to create a record, whether through a form, a screen flow, or a record creation action, and confirm it lands correctly with the right owner and relationship to their account.

Build tracking.

Give external users a view of their own submissions with current status, configured so they see their records and nobody else's, and verify that by logging in as two different users.

Add self-help.

Publish knowledge articles or content answering the questions that generate the most contact, and make them searchable from the portal.

Test a search as an external user.

Now configure notifications.

Set up automation informing the external user when their submission changes status, and confirm it fires for the right person.

Then test as a real user.

Have someone unfamiliar complete all three tasks in your portal without your help, watching without intervening.

Record every point they hesitated or failed, treat each as a design fault, and fix the worst three.

Measure the benefit.

Estimate what each self-service task saves in internal handling, stating your assumptions.

Finally, write what external users will still phone about and why.

Submit the task definitions, submission and tracking configuration with multi-user verification, the self-help content with search evidence, notification setup, the usability test with fixes, the benefit estimate, and the remaining gap note.

Before any portal goes live, someone must try to break it, and that is this task.

Inventory the exposure.

List every object, field, record, and page reachable by an authenticated external user and by an unauthenticated guest.

For each, state whether exposure is intended.

Now attack your own portal methodically.

Attempt to access another customer's record by direct URL.

Attempt to reach an object not in the navigation.

Attempt to see a field hidden from your profile through a report, list view, or related list.

Attempt to modify a record you should only read.

Attempt an action as a guest that should require login.

Record the result of each attempt with evidence.

Fix everything that succeeded when it should not have, and retest until every attempt is correctly denied.

Check the quieter exposures.

Examine what error messages reveal, whether record names appear in places they should not, and what the guest user profile can reach, since guest access is the most commonly overlooked hole.

Then review the sharing model as a whole, writing how a new record becomes visible to the right external user and nobody else, step by step.

Assess launch readiness.

State plainly whether you would put this portal in front of real customers, what remains unresolved, and what you would monitor in the first week.

Finally, write the single most serious issue you found in your own build and what caused it.

Submit the exposure inventory, the full attack log with evidence, the fixes and retests, the quieter exposure findings, the sharing model walkthrough, the readiness assessment, and the serious finding.