Experience Builder
Experience Builder is the Salesforce visual editor for designing and configuring Experience Cloud sites: customer help centers, partner portals, account portals, learning hubs, marketing microsites, and branded community sites.
Definition
Experience Builder is the Salesforce visual editor for designing and configuring Experience Cloud sites: customer help centers, partner portals, account portals, learning hubs, marketing microsites, and branded community sites. It gives admins a drag-and-drop canvas, a palette of components, theme and branding controls, navigation settings, audience targeting rules, and a draft-then-publish workflow. You assemble pages from components, set the look and feel, and deploy the site without writing custom front-end code for most pages.
Experience Builder is the Experience Cloud counterpart to Lightning App Builder. Both are no-code page editors, but Experience Builder targets external-facing sites for customers and partners, while Lightning App Builder targets internal record pages and app pages. Experience Builder supports the Lightning Web Runtime (LWR) framework and the older Aura framework. Salesforce recommends LWR for new sites because it is faster and built on the modern Lightning Web Components model.
How Experience Builder assembles a site
The canvas, palette, and property panel
Experience Builder opens on a canvas that shows one page of your site as it will render. A left palette lists the components you can place: standard components shipped by Salesforce, plus any custom Lightning Web Components your developers have exposed to the builder. You drag a component onto the canvas, drop it into a region, and a property panel opens on the right so you can set its attributes. The canvas updates as you change values, so you see the result before anyone visits the page. Components live inside content regions defined by the template, which keeps the layout consistent. On LWR sites you also work with sections and columns to control how regions stack on desktop and mobile. The top toolbar switches the device preview between desktop, tablet, and phone widths. This visual, attribute-driven model is why a Salesforce admin can build a working site without hand-writing HTML or CSS, while developers still extend the palette with code when a requirement goes past the standard set.
Pages, navigation, and URLs
A site is a set of pages, and Experience Builder manages all of them from one place. Out of the box you get pages like Home, Error, and Login, and you add object pages, record detail pages, and standalone pages as the site grows. Each page has its own URL, its own components, and its own visibility settings. Object pages are templated: one Account record page renders for every account, with the record context filling in the data. The Pages menu lists every page and lets you set the page that loads at the site root. Navigation is configured separately through navigation menus, where you define labels and link each item to an internal page, an external URL, a Salesforce object, or a menu label with no link. You can build more than one navigation menu and assign menus to audiences, so signed-in customers and anonymous visitors can see different menu items. Getting the page list and navigation right early saves rework, because URLs and menu structure are what visitors and search engines depend on.
Theme, branding, and CSS
Experience Builder includes a theme system that controls the visual identity of every page at once. The Theme panel sets colors, fonts, the logo, copyright text, and component styling like button shape and corner radius. Many templates support branding sets, which are saved collections of colors and images you can switch between, useful when one site serves several brands or seasonal campaigns. Because the theme applies site-wide, a single color change ripples across all pages instead of forcing edits page by page. For teams with strict brand guidelines, the built-in controls sometimes are not enough. LWR sites support a CSS editor and custom theme layout components, so developers can override styling and inject design tokens that match a corporate design system. The practical guidance is to push the built-in theme as far as it goes first, then reach for custom CSS only where the standard controls fall short. That keeps most of the styling maintainable in the UI, while the code-level overrides stay small and documented for the next person who edits the site.
Audience targeting and personalization
Audience targeting is how Experience Builder shows different content to different visitors without custom code. You create an audience by defining criteria: the user is authenticated, belongs to a profile or permission set, sits in a particular location, holds a certain field value, or matches a record-based condition. You then assign that audience to a page variation, to a single component, or to a branding set. A page variation is a separate version of a page that loads only for its audience, so VIP partners and trial users can land on the same URL yet see tailored layouts. Component-level targeting is finer grained: a promo banner shows only to logged-out visitors, while an account summary shows only to authenticated customers. Expression-based criteria let you target on field values and user attributes for more precise rules. Used with restraint this delivers real personalization cheaply. Used carelessly it gets fragile fast, because ten overlapping rules per component become hard to reason about. Document which audience drives each variation so future admins can predict what any given visitor will actually see.
LWR and Aura: choosing a framework
Experience Cloud sites are built on one of three frameworks, and the choice shapes everything you do in Experience Builder. Lightning Web Runtime (LWR) is the modern default. LWR sites are fast, use only Lightning Web Components, and are where Salesforce is investing, with templates like Build Your Own (LWR) and Microsite (LWR) plus the Enhanced LWR experience. Aura is the older framework. Aura-based templates such as Customer Account Portal and Partner Central still work and can use both Aura components and Lightning Web Components, but they are not the recommended starting point for a brand new build. Visualforce-backed Salesforce Tabs and Visualforce sites are the legacy option for maintaining old implementations. The framework is set when you create the site and is effectively baked in, so this is a decision to get right up front. For most new projects an LWR template is the right call. Pick Aura only when you specifically need an Aura-only component or a feature that the LWR templates do not yet support, since migrating frameworks later means rebuilding the site.
Drafts, publishing, and deployment
Every Experience Cloud site has a draft state and a published state, and Experience Builder keeps them separate on purpose. Your edits save as a draft, and visitors keep seeing the previously published version until you click Publish. That gap is the safety net for a production site: you can stage a redesign across many sessions and release it in one action when it is ready. Preview lets you load the draft as a chosen audience would see it, so you can catch differences between what a guest and a signed-in user get before customers do. Beyond a single org, Experience Builder configuration is metadata, which means it can be source-controlled and deployed through Salesforce DX and change sets rather than rebuilt by hand in each environment. Mature teams move site changes from sandbox to production the same way they move code, with the metadata under version control. Treating the site as a deployable artifact, not a one-off click-through, is what keeps a real Experience Cloud program reliable as it grows across multiple orgs and release cycles.
Configure an Experience Cloud site in Experience Builder
Experience Builder is reached from an existing Experience Cloud site, so you create the site first, then open it in the builder to customize pages, theme, and components.
- Create or open the site
In Setup, go to Digital Experiences then All Sites. Create a new site with a template (an LWR template for new builds) or click Builder next to an existing site to open it in Experience Builder.
- Set the theme and branding
Open the Theme panel and set colors, fonts, the logo, and component styling. Save a branding set if the site needs more than one look.
- Build pages and add components
Use the Pages menu to add or edit pages, then drag components from the palette onto the canvas and configure each one in the right-hand property panel.
- Configure navigation and audiences
Set up navigation menus and link each item to a page, object, or URL. Create audiences and assign them to page variations or components for personalization.
- Preview and publish
Use Preview to check the experience as different audiences, then click Publish to push the draft live. Visitors see the published version, not your in-progress drafts.
The runtime behind the template. LWR is the modern default for new sites; Aura supports both Aura and Lightning Web Components but is the legacy path.
Site-wide colors, fonts, logo, and component styling, optionally saved as switchable branding sets for multi-brand or seasonal sites.
Criteria that decide which visitors see a page variation, component, or branding set, based on authentication, profile, location, or field values.
One or more menus mapping labels to internal pages, objects, or external links, assignable per audience.
- The framework is chosen at site creation and cannot be swapped later without rebuilding, so decide LWR versus Aura before you start.
- Edits stay in draft until you click Publish; forgetting to publish is the most common reason a change does not appear on the live site.
- Stacking many audience-targeting rules per component makes a page hard to reason about; keep the rules few and documented.
- Custom Lightning Web Components only appear in the palette after they are configured for Experience Builder and deployed to the org.
Prefer this walkthrough as its own page? How to Experience Builder in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Experience Builder.
Hands-on resources to go deeper on Experience Builder.
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 does Experience Builder let admins and developers assemble?
Q2. Experience Builder is the Experience Cloud counterpart to which internal-facing Salesforce editor?
Q3. Which site framework is the modern, recommended path that Experience Builder supports for new sites?
Discussion
Loading discussion…