Community Cloud — now branded Experience Cloud as of 2021 but still widely referred to by the legacy Community Cloud name in customer contracts — sits in one of the more confusing corners of the Salesforce license catalog. The license types are numerous, the pricing structures vary across types, and the optimization opportunity is consistently substantial. Across the 500-plus engagements our advisory has supported, Community Cloud license optimization has frequently produced double-digit-percentage savings on the line, with the typical optimization driven by structural mismatches between licensed populations and actual use cases. This guide walks through the 2026 Community Cloud / Experience Cloud license catalog, the pricing dynamics, and the optimization moves that produce material savings.
The Community Cloud license types in 2026
The current license types include:
| License type | Typical use case | Pricing model |
|---|---|---|
| Customer Community | Self-service customer portals, B2C | Per login or per member/month |
| Customer Community Plus | Enhanced customer portals with limited CRM | Per login or per member/month |
| Partner Community | Channel partner portals | Per login or per member/month (typically higher) |
| External Apps License | Broader external user capabilities | Per user/month at premium rates |
| Customer Community for Lightning External Apps | Modern Lightning external app deployments | Custom pricing |
The per-login versus per-member pricing distinction is one of the most important Community Cloud license decisions, and it materially affects the economics. Per-login pricing charges for each active login event (typically monthly), while per-member pricing charges per provisioned user per month regardless of login activity.
The per-login versus per-member decision
The economic model differs substantially:
Per-login works well for use cases with large provisioned populations but low login frequency — customer portals where customers may log in monthly or quarterly, support portals where customers come back as-needed, partner portals where partner staff log in for specific transactions. The cost scales with actual activity.
Per-member works well for use cases with smaller populations but high login frequency — channel partners actively using the portal as a primary work surface, customer success portals where customers log in daily or weekly, B2B partner deployments where the partner staff are essentially extended employees.
The wrong choice can produce dramatic cost differences. A 100,000-user customer portal with average 1 login per quarter per user would pay substantially less on per-login than on per-member. A 1,000-user partner portal with daily logins would pay substantially less on per-member than on per-login. The modeling exercise before signing is critical.
Modeling the choice
The decision should be based on actual or projected usage patterns. The key metrics:
- Provisioned member count (the total number of users in the portal)
- Active member ratio (the percentage of provisioned members who log in at least monthly)
- Average login frequency among active members
- Total monthly login events (active members times average frequency)
The per-login cost equals (monthly login events times per-login rate). The per-member cost equals (provisioned members times per-member rate). The break-even login frequency at which the two models cost the same can be calculated; the choice should fall on the lower-cost side of that break-even for the expected usage.
The Customer Community versus Partner Community decision
Partner Community licenses are positioned for channel partner scenarios and include broader CRM capabilities than Customer Community. The pricing is correspondingly higher. The decision should align license type with actual user populations:
Customer Community fits when the external users are end customers accessing self-service capabilities — account management, order status, support cases, knowledge base, billing information. The functional scope is appropriate for customer-facing scenarios.
Customer Community Plus fits when end customers need somewhat broader capabilities — access to specific custom objects, ability to work with opportunities in a customer-facing context, broader reporting capabilities.
Partner Community fits when external users are channel partners working through Salesforce data — submitting deal registrations, working partner-side leads and opportunities, accessing partner-specific reports and analytics. The broader CRM access is appropriate for partner scenarios.
External Apps License fits for scenarios with broader external user capabilities, including custom object access beyond the standard Community licenses.
The optimization opportunity often involves moving users between license types. Users licensed at Partner Community who only need Customer Community capabilities, or users licensed at External Apps who fit Customer Community Plus, represent over-licensing. The audit can produce meaningful savings.
The custom object limits
One of the recurring constraint discussions on Community Cloud licenses involves custom object access. The license types have differing limits on custom object access:
- Customer Community: limited custom object access (typically 10 custom objects with limited capabilities)
- Customer Community Plus: broader custom object access (typically more custom objects with broader CRUD capabilities)
- Partner Community: broader custom object access
- External Apps License: broadest custom object access
The limits affect deployment options. Organizations with custom object-heavy deployments may need to upgrade license types to accommodate the customizations, or may need to restructure the data model to fit within the lower-tier license limits. The decision should align with the deployment requirements rather than discovering the constraint post-purchase.
The page view consumption model
Beyond the per-login and per-member pricing, Community Cloud also has page view consumption tied to guest user activity (covered separately in our guest user license compliance guide). For internal/login-based community usage, the page view consumption is typically not the binding constraint, but for community deployments with significant anonymous/guest user traffic, the page view costs can be substantial.
The 34 percent reduction context
Across the engagements our advisory has supported, Community Cloud optimization has been a consistent source of savings. The typical findings:
- Per-member licenses applied to populations with low login frequency, where per-login would have produced substantially lower cost
- Per-login licenses applied to populations with high login frequency, where per-member would have produced substantially lower cost
- Partner Community licenses applied to populations that actually fit Customer Community Plus scope
- External Apps License applied to populations that fit narrower license scope
- Significant provisioned-member counts with very low active-member ratios, indicating shelfware on the per-member side
The 34 percent average reduction figure applies to Community Cloud line items as much as to core CRM, and the optimization often comes from restructuring the license mix at renewal rather than from negotiating discount on the existing structure.
Negotiation moves on Community Cloud
1. Model the per-login versus per-member decision. Run the usage modeling with both pricing structures and select the lower-cost option. This single decision often produces the largest savings.
2. Audit the license tier mix. Validate that the Customer Community, Customer Community Plus, Partner Community, and External Apps License assignments match the actual functional needs of each population.
3. Bundle Community Cloud with broader Salesforce deals. Standalone Community Cloud negotiations rarely produce strong discount. Bundle Community Cloud into renewal or expansion conversations.
4. Negotiate page view inclusions. For deployments with significant guest user traffic, negotiate page view inclusion above the standard bundle.
5. Lock per-login and per-member pricing. The list pricing on Community Cloud has crept up over the years. Lock the per-login and per-member rates for the contract term against mid-term changes.
6. Address mid-term tier changes. Document the economics of mid-term changes between license tiers if the user populations may evolve.
7. Negotiate the True-Up dynamics. Per-member license counts can grow during the term if the portal expands. Document the True-Up pricing and the renewal-time rebalancing capability.
8. Validate the storage and API allocations. Community Cloud deployments often need additional storage and API allocations beyond the standard inclusions. Negotiate the allocations explicitly.
The optimization process
The typical Community Cloud optimization engagement follows several stages:
Stage 1: Inventory
Document every Community Cloud license currently provisioned: which license type, which population, what the user is doing in the portal. The inventory establishes the baseline.
Stage 2: Usage analysis
Analyze the actual usage patterns: login frequency, page views, custom object access, transactions performed in the portal. The usage analysis identifies the actual versus assumed activity patterns.
Stage 3: Right-sizing
Map the populations to the appropriate license types based on actual usage patterns. Identify the populations that should move between license types. Identify the populations that are not active and that should be deprovisioned.
Stage 4: Pricing model selection
For each population, validate the per-login versus per-member decision based on actual usage. Migrate populations to the lower-cost pricing model where appropriate.
Stage 5: Renewal negotiation
Bring the right-sized Community Cloud mix into the renewal negotiation alongside broader Salesforce conversations. The bundled negotiation typically produces stronger outcomes than a standalone Community Cloud negotiation.
What to verify before signing Community Cloud terms
- The per-login versus per-member decision has been modeled with actual or projected usage patterns.
- The license tier mix (Customer Community, Plus, Partner, External Apps) matches actual functional needs.
- The custom object access on the selected license types supports the deployment requirements.
- Per-login and per-member pricing is locked for the contract term against mid-term changes.
- Page view inclusions match expected guest user traffic with reasonable headroom.
- API call allocations account for portal API traffic alongside the rest of the deployment.
- Storage allocations support the portal data volume.
- The True-Up structure for mid-term member count growth is documented at favorable rates.
- Renewal-time rebalancing between license types and between pricing models is permitted without penalty.
- Renewal price caps apply to Community Cloud line items.
- Mid-term license changes (downgrades, deprovisioning) are permitted within the contract.
Community Cloud license optimization is one of the highest-leverage opportunities in many Salesforce contracts. The combination of multiple license types, dual pricing models (per-login and per-member), custom object considerations, and the recurring evolution of customer-facing and partner-facing portal use cases creates substantial optimization surface area. The $420 million in cumulative savings our advisory has delivered includes a meaningful Community Cloud component, sourced from right-sized license tier mixes, optimized pricing model selection, and structurally improved contract economics at renewal.
For most organizations, the right approach is to treat the Community Cloud conversation as a structural optimization opportunity at every renewal cycle, not as a routine license purchase. The renewal-time discipline of running the usage analysis, modeling the alternative structures, and negotiating the resulting configuration as part of broader Salesforce deals consistently produces material savings against what would have been the default renewal economics.
The portal-architecture decisions that affect licensing
Beyond the license-mix optimization, several architectural decisions affect Community Cloud economics:
Single portal versus multiple portals. Some organizations operate multiple Community Cloud sites (separate customer portal, partner portal, employee portal). Each site has its own configuration and its own license accounting. Consolidating into fewer sites can simplify operations but may produce license-tier issues if the user populations have differing needs.
Branded portal versus integrated experience. A branded Community Cloud site has different operational considerations than a fully integrated experience embedded in a corporate website. The licensing implications include the page view considerations and the API call patterns.
Mobile-first versus desktop-first. Mobile-first portal designs have different usage patterns than desktop-first designs. The login frequency and session patterns can differ substantially, affecting the per-login versus per-member economics.
Self-service versus assisted-service. Self-service portals (where customers do the work themselves) have different usage patterns than assisted-service portals (where customer service agents help customers through the portal). The licensing implications depend on the specific patterns.
Authenticated versus mixed authenticated/anonymous. Portals with significant anonymous traffic have additional considerations around guest user licensing alongside the authenticated user economics.
The user lifecycle management discipline
The operational discipline around Community Cloud user lifecycles materially affects the licensing economics. The key practices:
Onboarding automation. Automated provisioning of users into the appropriate license tier based on their role and use case. Manual provisioning frequently produces over-licensing through default to the higher tier.
Activity monitoring. Continuous monitoring of user activity to identify inactive users who should be deprovisioned or moved to per-login pricing.
Periodic re-validation. Quarterly re-validation of user populations to identify role changes, departures, and tier-mismatch evolutions.
Self-service deprovisioning. For B2B portals, allowing customers to manage their own user populations (adding and removing users) reduces administrative overhead and supports more accurate license accounting.
Sunset and reactivation patterns. Users who become inactive can sometimes be sunset (deprovisioned but with reactivation capability) rather than fully deprovisioned, preserving the customer relationship without the ongoing license cost.
The Slack-Community Cloud crossover considerations
Since Salesforce’s acquisition of Slack, the messaging and collaboration capabilities of Slack have created overlap with some Community Cloud use cases. Customer-facing collaboration, partner collaboration, and B2B engagement can sometimes be served better by Slack Connect than by a Community Cloud portal. The 2026 evaluation should consider:
- Whether B2B partner collaboration belongs in Slack Connect or in a Partner Community
- Whether customer-facing engagement is better served by a Slack-based experience or a Community Cloud portal
- How the licensing economics compare between Slack Connect and Community Cloud for equivalent use cases
- The data integration patterns that connect Slack-based engagement back to Salesforce CRM data
For some organizations, the Slack-Community Cloud rationalization produces meaningful savings and improved user experience. For others, the two products serve genuinely different use cases and the consolidation does not apply. The evaluation should be specific to the use cases at hand.
The renewal-time restructuring opportunity
Community Cloud renewals offer particularly substantial restructuring opportunities because of the multiple variables involved. The renewal-time decisions:
- Per-login versus per-member rebalancing based on observed usage
- License-tier rebalancing based on observed functional usage
- Member-count rebalancing based on observed active member counts
- Page view allocation rebalancing based on observed traffic patterns
- Custom object allocation rebalancing based on deployment evolution
- Architecture rebalancing (single portal versus multiple portals)
The cumulative effect of all the rebalancing decisions can produce dramatic economic improvements compared to renewing at the existing structure. The discipline of running the comprehensive analysis at every renewal cycle rather than accepting default renewals is the foundation of the sustained optimization.