Experience Cloud identity and access is the set of design choices that control who can log in, what they can do, and what records they can see. A strong approach starts with an identity strategy (SSO and user lifecycle), a clean permission model (profiles + permission sets), and a deliberate sharing model (roles, sharing sets, and “who sees what” rules). The goal is secure, least-privilege access that still supports real portal tasks.

This guide is most useful for Salesforce teams building customer or partner portals who need external users to access cases, requests, deals, assets, or knowledge, without turning security into an afterthought or an endless exception process.

If you don’t define audiences and authentication first → then provisioning and support become chaos.
If you mix permissions and sharing concepts → then you either overexpose data or users can’t see anything.
If you don’t test “real user scenarios” → then launch day becomes a security and adoption fire drill.

A “good” identity & access model includes:

• A clear user taxonomy (customer vs partner vs employee, plus tiers)

• SSO decisions and lifecycle ownership (provision/deactivate)

• Profiles for baseline access + permission sets for additions

• A sharing matrix for each object (cases, deals, MDF, assets)

• Regular audits and change control for access updates

Step 1: Start With User Types and Their Jobs (Not With Profiles)

The cleanest designs start from what users must do.

What you do
List your portal audiences and top tasks:

• Customer portal

  • Search knowledge

  • Submit/track cases

  • View assets/entitlements (if applicable)

• Partner portal

  • Register deals

  • Submit/track MDF

  • Access enablement resources

• Employee community

  • Knowledge and collaboration

For each audience, define:

• Minimum “must-do” tasks (MVP)

• Tier differences (partner tiers, customer tiers)

• Data sensitivity level (what must never be exposed)

Outputs you want

• User taxonomy (user type → tasks → sensitivity)

• MVP access requirements per user type

Step 2: Choose Authentication: SSO vs Username/Password (Support vs Friction)

Authentication affects adoption and long-term support cost.

What you do
Decide between:

• SSO (recommended for many enterprise customer/partner scenarios)

  • Pros: fewer password resets, better security, centralized access control

  • Cons: requires identity provider coordination and testing

• Username/password

  • Pros: fast to start

  • Cons: ongoing support burden, higher friction, more lockouts

Also decide:

• MFA requirements

• Login discovery flow (“how do users find the portal?”)

• “Request access” path (self-serve onboarding vs internal provisioning)

Outputs you want

• Authentication decision doc (why you chose it)

• Support plan for login issues (who owns what)

Quick win

• Even if you start with username/password, design your user lifecycle so you can move to SSO later without redoing everything.

Step 3: Define User Lifecycle (Provisioning, Updates, Deactivation)

External user lifecycle is where portals quietly break over time.

What you do
Define:

• Who creates users (self-registration, admin, channel manager)

• How users are associated to the right account/partner record

• How roles/tier are assigned (and updated)

• How access is removed:

  • Partner employee leaves

  • Customer changes orgs

  • Contract ends

Outputs you want

• Lifecycle flow diagram (create → manage → deactivate)

• Ownership model (ops vs admin vs partner manager)

Step 4: Understand the Two Layers: Permissions vs Record Visibility

This prevents the most common confusion.

Layer A: Permissions = what actions are allowed

Examples:

• Create Case

• View Knowledge

• Edit Deal Registration

• Upload MDF proof

Layer B: Sharing/visibility = which records can be seen

Examples:

• Which cases does this user see?

• Which deals does this partner user see?

• Which assets belong to this account?

Decision logic

• If a user can’t see an object at all → it’s a permissions issue.

• If they can access the object but can’t see the right records → it’s a sharing issue.

Step 5: Profiles + Permission Sets (Build a Clean Permission Model)

Portals get messy when profiles are used as “everything.”

What you do

• Use profiles for baseline access per user type (keep the number small)

• Use permission sets to add capabilities:

  • Partner tier upgrades

  • Pilot features

  • Special workflows (e.g., MDF reimbursement)

• Use permission set groups if you need packaged bundles

Best practices

• Prefer additive permissions (permission sets) over creating many profiles

• Name clearly (e.g., Partner Portal - Base, Partner Portal - MDF Submitter)

• Document what each permission set enables

Outputs you want

• Permission catalog (profile/perm set → what it grants)

• A “do we need a new permission set?” checklist (avoid sprawl)

Step 6: Roles and Sharing: Build the “Who Sees What” Matrix

Sharing is the heart of portal security.

What you do
For each object external users will access (Cases, Requests, Deals, MDF, Assets), define:

• Who should see it (user type)

• What scope (own records, account records, partner account records)

• What access level (read-only, edit, create)

• Exceptions (VIP, escalations, restricted record types)

Typical portal patterns

• Customers see:

  • Their own cases + optionally all cases for their account

• Partners see:

  • Deals/MDF they submitted + optionally those for their partner account

Outputs you want

• Sharing matrix (object → scope → rule)

• A test script set (“User A can see X, cannot see Y”)

Step 7: Plan for Knowledge Access (Public vs Authenticated)

Knowledge strategy impacts deflection and security.

What you do
Decide:

• What content is public (if any)

• What requires login (customer-only or partner-only)

• Whether partner enablement content is tier-gated

• How you prevent “leakage” of internal docs

Outputs you want

• Knowledge access tiers (public vs authenticated vs role-based)

• An article governance plan (owners + review cadence)

Step 8: Testing and Auditing (The Part That Prevents Launch Surprises)

Portals must be tested as real external users.

What you do
Test scenarios by user type and tier:

• Can log in (SSO or password)

• Can complete top tasks

• Can see only the correct records

• Cannot access restricted data

• Notifications work as expected

Add ongoing audits:

• Quarterly access review (especially partner users)

• Remove inactive users

• Validate tier assignments and permission drift

Outputs you want

• A pre-launch access test plan

• A quarterly audit checklist

Common Pitfalls (And How to Avoid Them)

Pitfall: Designing security after the UX is built
Fix: Build the sharing matrix early and test it throughout.

Pitfall: Creating a new profile for every exception
Fix: Keep profiles minimal; use permission sets for add-ons.

Pitfall: Users can log in but can’t see records
Fix: Separate permissions issues from sharing issues and debug systematically.

Pitfall: No lifecycle plan for partner turnover
Fix: Define provisioning/deactivation ownership and automate where possible.

Pitfall: Knowledge content leaks
Fix: Tier content access and govern article publishing.

Frequently Asked Questions

Do I need SSO for Experience Cloud?
Not always, but SSO reduces login friction and password reset volume. It’s often the best long-term approach for partner and enterprise customer portals.

What’s the difference between profiles and sharing?
Profiles/permission sets control what features a user can use. Sharing controls which records they can see.

How do we let customers see all cases for their account?
Use an account-based visibility approach where appropriate, and confirm the business rules (some orgs want “my cases only,” others want “account cases”).

How do we avoid exposing sensitive data?
Use least privilege, restrict fields and record types, and test with real external user scenarios before launch.

How often should we audit portal access?
At least quarterly for partner portals, and whenever contracts, tiers, or org structures change.

Book an Identity & Access Working Session

If you want an Experience Cloud portal that’s secure and usable, book time with our team. We’ll map your user types and tasks, design a clean permission model (profiles + permission sets), and build a sharing matrix you can test before launch, so you avoid access surprises and adoption problems.