Community Application
A Community Application is a Salesforce site that exposes a controlled slice of org data and functionality to external users through a branded portal.
Definition
A Community Application is a Salesforce site that exposes a controlled slice of org data and functionality to external users through a branded portal. It runs on the Experience Cloud platform, renamed from Community Cloud in 2021, and is built from a template (typically Lightning Web Runtime, Aura, or a legacy Visualforce theme) that ships with pages, navigation, and a theme already wired to Salesforce records.
The external users who sign in are not standard internal Salesforce users. They hold one of the external license types (Customer Community, Partner Community, or their Plus and Login variants), and their record access is governed by a separate sharing model built around their Account or Contact. A single Salesforce org can host multiple Community Applications, each pointed at a different audience with its own URL, branding, and login flow.
How a Community Application is wired into the org
Templates and the choice of runtime
A Community Application is always built from a template, and the template decides which page-building tool you use and which components are available. LWR (Lightning Web Runtime) is the modern default for new builds, runs on Lightning Web Components, and offers faster page loads with stricter performance budgets. Aura sites use the older Lightning runtime and accept any Aura or Lightning component but render more slowly under load. Salesforce Tabs + Visualforce is the legacy option, kept for orgs that still run Visualforce-heavy customer portals, and Salesforce no longer adds features to it. Once a site is created on a template, you cannot swap templates in place. Moving from Aura to LWR means rebuilding the site from scratch.
External user licenses and what they include
External users do not log in with the same license as your internal staff. They hold a Customer Community, Customer Community Plus, Partner Community, or one of the Login-based equivalents. The Plus variants add role hierarchy and sharing rule support that the standard Customer Community license lacks. Partner licenses include the Lead, Opportunity, and Campaign objects that Customer licenses cannot see. The license drives the cost model, the data they can reach, and the sharing options available, so picking the right license up front matters more than the template choice.
Sharing through the Sharing Set and Share Group pair
External users do not get records through standard role hierarchy or sharing rules in most cases. Sharing Sets give them access to records related to their Account or Contact (for example, all Cases on my Account). Share Groups let internal users see records owned by high-volume Customer Community users, who otherwise sit outside the role hierarchy. For Partner Community users, the external role hierarchy on the Account record (super user vs standard) decides who at the partner firm can see whose data. Get this wrong and you either expose too much or your portal feels broken because users cannot see records they expect to see.
Experience Builder and the page layer
Pages in an LWR or Aura site are built in Experience Builder, a drag-and-drop editor for layouts, components, and theming. You can drop standard Salesforce components like Record Detail, List View, or Related Lists, install components from AppExchange, or build your own LWCs and use them in Builder. Routes are configured per page, with audience targeting that lets the same site show different layouts to different visitor profiles or geographies. The Builder also owns the theme (fonts, colors, header, footer), and changes here propagate to every page.
Activation, the My Domain prefix, and Digital Experiences
Before any site can go live, the org must enable Digital Experiences (Setup, Digital Experiences, Settings, Enable Digital Experiences). This is a one-way switch. Every site then sits under a subdomain like yourdomain.my.site.com/sitename, or a custom vanity domain if you provision one through Salesforce or your CDN. Activating the site flips it from draft to live and starts billing for member-based licenses if you are on that pricing model. Inactive sites are invisible to external users even if their URLs are guessed.
Authentication and the login flow
External users sign in through a login page that the site owns. Out of the box, Salesforce supplies a username and password form, but most production deployments swap in single sign-on through SAML, OpenID Connect, or social providers like Google, Facebook, or Apple. Self-registration is configurable per site: you can require admin approval, auto-create a Contact record for the new user, or restrict registration to an invite list. Forgot-password flows, MFA enforcement, and session timeouts are also tuned per site, not globally.
Performance budgets unique to LWR
LWR sites are publicly cached at the edge and have strict component limits. Apex methods called from LWR components must be @AuraEnabled(cacheable=true) to participate in caching. Components that mutate data on page load slow renders significantly. Image sizes, page weight, and the number of components per page all affect Lighthouse scores, and Salesforce surfaces these in the Site Performance dashboard. Aura sites do not have the same cache layer, so the same problems show up as raw server load instead.
How to spin up a Community Application
Spinning up a Community Application means enabling Digital Experiences for the org, picking a template, configuring access for the right license type, and activating the site under a domain. The order matters because Digital Experiences is a one-way org setting that you cannot revert later.
- Enable Digital Experiences
In Setup, go to Digital Experiences, then Settings, then check Enable Digital Experiences and pick a domain prefix. The prefix becomes the URL prefix for every site and cannot be changed once set, so coordinate with marketing before you commit.
- Create the site from a template
Setup, Digital Experiences, All Sites, New. Pick LWR for any net-new build unless you have a specific need for an Aura-only component. Name the site and assign the URL path that follows the domain prefix.
- Provision external user licenses
Buy the right license count (Customer Community, Customer Community Plus, Partner Community, or Login-based) through your account executive. Login-based licenses bill per login per month and suit infrequent users; member-based licenses bill per active user and suit daily users.
- Configure profile and permission sets
Clone a standard external profile such as Customer Community User and tighten or expand object access. Create permission sets for any add-on capabilities. Assign profiles to Contacts when you enable them as Community users.
- Set up Sharing Sets and Share Groups
For Customer Community access patterns, configure Sharing Sets to grant record access via the Account or Contact relationship. Add internal users to Share Groups so they can see records owned by external high-volume users.
- Build pages in Experience Builder
Open the site in Experience Builder. Configure the theme, set the navigation menu, drop components on each page, and configure audiences if different visitor groups should see different layouts.
- Activate the site
From the Administration workspace, click Activate. The site goes live at its configured URL. Test from an external user account in incognito. Do not test as an internal admin viewing as, since that bypasses several sharing rules.
- Digital Experiences cannot be disabled once enabled. Test the impact in a sandbox first.
- The domain prefix is one-way and applies to every site in the org. Coordinate with marketing before locking it in.
- Customer Community license users cannot use role hierarchy or sharing rules. If you need either, switch the license tier to Customer Community Plus before users are provisioned.
- Sharing Sets only grant access. They cannot remove access already granted by other mechanisms.
- LWR sites cache aggressively. Records updated on the org may take minutes to reflect on the site unless you invalidate cache or call non-cacheable Apex.
Trust & references
Cross-checked against the following references.
- Experience Cloud OverviewSalesforce Help
- Set Up and Manage Experience Cloud SitesSalesforce Help
- Sharing SetsSalesforce Help
Straight from the source - Salesforce's reference material on Community Application.
- Build LWR SitesSalesforce Help
- Experience Cloud Developer GuideSalesforce Developers
Hands-on resources to go deeper on Community Application.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is a Community Application?
Q2. Who interacts with a Community Application?
Q3. What controls external user access in a Community Application?
Discussion
Loading discussion…