Portal & Community Security: Experience Cloud Access

Portal security, in the context of Experience Cloud (formerly Community Cloud), introduces a second layer of complexity to the Salesforce security model. External users (customers, partners, suppliers) have different license types, different sharing behavior, and different security constraints than internal users. Getting portal security wrong is a common CTA failure point because candidates apply internal security patterns to external user scenarios.

External User Architecture Overview

Figure 1. Internal and external users operate under separate role hierarchies and separate OWD settings, but converge at the sharing rules and FLS layer. This separation is why external OWD must be configured independently. Changing the internal OWD does not automatically secure external access.

External User License Types

The license type determines what a user can do and how sharing works. Getting this wrong locks you into expensive upgrades later.

License Comparison

License	Data Access	Sharing Behavior	Role Hierarchy	Record Ownership	Cost
Customer Community	Own records + shared	Community sharing rules	Portal roles (under Account)	Yes	Lowest
Customer Community Plus	Own + shared + reports	Standard sharing + community rules	Full portal role hierarchy	Yes	Medium
Partner Community	Own + shared + reporting	Standard sharing + partner rules	Partner role hierarchy	Yes	Medium-High
External Apps	Own records + shared	Community sharing rules	Portal roles	Yes	Lowest (API optimized)
Channel	Similar to Partner	Standard sharing + partner rules	Partner role hierarchy	Yes	Medium-High
Guest User	Only what sharing rules grant	Guest user sharing rules only	None	No	Free

License Selection Decision

Figure 2. License selection determines sharing behavior, role hierarchy participation, and cost. Selecting Customer Community Plus when Community suffices adds unnecessary role hierarchy complexity and cost at scale. The license choice is an architectural decision, not just a commercial one.

External OWD

Salesforce has separate OWD settings for external users. The External OWD can be the same as or more restrictive than the internal OWD, but never less restrictive.

Internal vs External OWD

Internal OWD	Allowed External OWD	Why
Private	Private only	External cannot be less restrictive
Public Read Only	Private or Public Read Only	Can restrict external further
Public Read/Write	Private, Public Read Only, or Public Read/Write	Can restrict external further

External OWD Defaults

When you change an internal OWD, the external OWD defaults to the same value. But if there are external users, the external OWD should almost always be MORE restrictive than the internal OWD. Review external OWD separately for every object.

External OWD Design Approach

Figure 3. External OWD is configured per object after internal OWD is set. The default answer to “should external users see each other’s records?” is almost always no. External users from different companies should be isolated, with sharing rules used only for documented exceptions.

Portal Role Hierarchy

External users have their own role hierarchy that sits beneath their Account in the internal role hierarchy. The structure differs between customer and partner portals.

Portal Role Hierarchy Structure

Figure 4. Portal role hierarchies sit beneath the internal hierarchy, anchored to the Account owner. The implicit sharing connection means the Account Manager automatically sees portal users’ records. This is a key access pathway that must be accounted for when designing external user security.

How Portal Roles Are Auto-Created

When you create the first community user on an Account, Salesforce automatically generates portal roles for that Account. This auto-creation affects role hierarchy size and sharing calculations.

Figure 5. Portal role auto-creation is triggered by license type. Community Plus and Partner licenses create 3 roles per Account, meaning 10,000 partner accounts generate up to 30,000 portal roles. This role volume directly impacts sharing group maintenance time and is a key scaling consideration.

Role Volume at Scale

Each Account with community users generates up to 3 roles. An org with 10,000 partner accounts creates up to 30,000 portal roles. This bloats the role hierarchy and increases group membership table maintenance time. Use Customer Community (1 role) over Community Plus (3 roles) when hierarchy is not needed. Configure the number of customer roles (1-3) under Setup > Communities Settings.

Portal Role Hierarchy Levels

License Type	Available Roles	Default Roles
Customer Community	1 role (flat)	User
Customer Community Plus	3 roles (Executive, Manager, User)	All three created per Account
Partner Community	3 roles (Executive, Manager, User)	All three created per Account
External Apps	1 role (flat)	User

Community License Role Limitation

Customer Community (non-Plus) users do NOT participate in the portal role hierarchy. They are flat: each user can only see their own records plus records shared explicitly. This is by design for high-volume, low-cost scenarios. If a customer needs hierarchical visibility, use Customer Community Plus.

High-Volume Customer Portal Users

Customer Community and External Apps licenses inherently use the high-volume sharing architecture (sharing sets, share groups) regardless of user count. These users have special sharing behavior distinct from standard portal users.

HVCP Sharing Behavior

Feature	Standard Portal Users	HVCP Users
Share tables	Use standard share tables	Use separate sharing tables (optimized for scale)
Role hierarchy	Participate in portal hierarchy	Do NOT participate in hierarchy
Sharing rules	Ownership + criteria-based	Sharing sets + share groups
Record visibility	OWD + hierarchy + rules	Own records + sharing sets only
Scale	Moderate (thousands)	Massive (millions)
Performance	Standard sharing calculation	Optimized; no hierarchy computation

Sharing Sets

Sharing Sets are the mechanism for granting HVCP users access to records beyond their own.

Figure 6. A Sharing Set grants HVCP users access to records by matching a lookup field on the target object to the user’s Account. This lookup-based matching is more scalable than standard sharing rules for millions of external users, but requires careful field selection to avoid cross-account data leakage.

Example: A Sharing Set grants Customer Community users Read/Write access to Cases where Case.AccountId matches the user’s Contact.AccountId. This means portal users see Cases related to their own Account.

Sharing Set Data Flow

Figure 7. Sharing Set evaluation is a simple Account ID comparison: the portal user’s Contact.AccountId must match the target record’s AccountId lookup field. Cases belonging to a different Account are never returned, enforcing tenant isolation without any explicit sharing rule configuration.

Share Groups

Share Groups grant internal users access to HVCP user records. This is the reverse direction: internal users needing to see portal users’ data.

Mechanism	Direction	Purpose
Sharing Sets	Grant external users access to records	”Portal users see their Account’s Cases”
Share Groups	Grant internal users access to HVCP records	”Support agents see portal users’ Cases”

Guest User Security

Guest users (unauthenticated visitors) have the most restricted access in Salesforce. Since 2020, Salesforce has progressively tightened guest user security.

Guest User Security Restrictions

Restriction	Details	Since
No record ownership	Guest users cannot own records	Always
Explicit sharing rules required	Must use guest user sharing rules for any access	Winter ‘20
Secure guest user record access	Records created by guests are owned by the site’s default owner	Spring ‘20
Object permissions must be explicit	No implicit access to any object	Winter ‘21
API access disabled by default	Guest users cannot access APIs without explicit configuration	Spring ‘21
View All / Modify All blocked	Cannot grant these permissions to guest users	Always
Sharing rules limited	Only criteria-based guest user sharing rules	Winter ‘21

Guest User Security is a CTA Red Flag

If the architecture exposes any data to unauthenticated users, the CTA board WILL probe this aggressively. You must justify every piece of data visible to guest users, explain the sharing rules, and demonstrate the principle of least privilege. Over-exposure of guest user data has caused real-world data breaches.

Guest User Architecture Pattern

Figure 8. Guest user security follows strict explicit opt-in: every object, field, and sharing rule must be deliberately enabled. The default posture is deny everything. Guest users who can access any data represent a potential public data exposure because they are unauthenticated internet visitors.

Guest User Best Practices

1. Audit guest user profiles quarterly. Permissions creep over time.
2. Use criteria-based sharing rules only. Ownership-based rules are not available for guest users.
3. Never expose PII to guest users. Even masked data is risky.
4. Remove all unnecessary object permissions. Explicit opt-in only.
5. Disable guest user API access unless there is a specific, documented need.
6. Run Salesforce Health Check. It flags guest user security issues.

Community-Specific Sharing Rules

Experience Cloud supports additional sharing rule types specific to external users.

Sharing Rule Types for Communities

Rule Type	Applies To	Based On	Use Case
Ownership-based	All external users	Record owner’s role	”Partner Executive’s records shared with Partner Managers”
Criteria-based	All external users	Field values	”Cases with Status = Escalated shared with Partner Executives”
Guest user sharing	Guest users only	Field values (criteria)	“Knowledge Articles where IsPublished = true shared with guest users”
Sharing Sets	HVCP users	Lookup field match	”Cases shared where Case.AccountId = User’s AccountId”

Portal Security Design Process

Figure 9. Portal security design must be sequential: license type determines sharing behavior, which constrains how OWD and sharing sets can be configured. Skipping step 9 (testing with each actual license type) is the most common cause of undetected external user data exposure before go-live.

Portal Security Anti-Patterns

Anti-Pattern	Risk	Correct Approach
Using internal OWD for external users	Over-exposure of data between accounts	Set External OWD to Private separately
Giving guest users object permissions by default	Data breach; unauthenticated access	Explicit opt-in for every object
Using Customer Community Plus when Community suffices	Unnecessary cost and complexity	Start with Community; upgrade only if reporting/hierarchy needed
Ignoring implicit sharing for portal users	Portal users see parent Account data	Audit implicit sharing paths
Not testing with each license type	Permission gaps or over-exposure	Create test users for each license type
Sharing too much via Sharing Sets	Cross-account data leakage	Use the narrowest lookup field match possible

Related Topics

• Sharing Model: internal sharing model is the foundation; portal extends it
• Identity & SSO: external user authentication and social sign-on
• Field & Object Security: external user profiles and permission sets
• Security Best Practices: portal-specific best practices
• Decision Guides: license and portal architecture decision trees

Sources

• Salesforce Help: Experience Cloud Security
• Salesforce Help: External User Licenses
• Salesforce Help: Guest User Security
• Salesforce Help: Sharing Sets
• Salesforce Help: High-Volume Portal Users
• Salesforce Help: Partner User Roles
• Salesforce Help: Community Role Configuration
• Salesforce Architects: Experience Cloud Architecture
• Salesforce Security Guide: Guest User Best Practices
• Trailhead: Optimizing Role Hierarchy and Account Roles