Spring ’26 introduces Screen and Component Styling Overrides in Flow Builder, giving admins more control over how screen flows look and feel without custom code.
As with any feature that expands customization, it comes with responsibility. Styling flexibility is powerful, but without a clear approach it can create inconsistency, or a screen that looks like it lost a fight with a rainbow.
Our approach to screen styling and branding was designed with this balance in mind. Here’s a practical way to address them.
The key word in this feature is overrides.
Styling overrides are evaluated after your org or site theme is applied. With them, you can adjust screen and component styling such as background, text, and border colors, along with border weight and radius.
Themes remain the foundation for consistency, reusability, and long-term maintainability. If a visual change should apply broadly across flows, it belongs there.
Overrides exist to handle intentional exceptions and to fill the gaps themes can’t cover.
Styling in Flow Builder follows a layered model where each level builds on the one before it.
Within flow-level overrides, styling can be applied at two scopes.
Each layer builds on the previous one rather than replacing it. Understanding this order makes it easier to decide where a change belongs.
One common scenario is brand alignment across different contexts. Experience Cloud themes often provide broader styling flexibility because they support external, customer-facing experiences where branding is highly visible. Internal Lightning experiences are optimized for consistency and productivity, which means granular visual adjustments are less frequently required. In certain cases, however, you may want to make a targeted refinement to align with organizational branding or support a specific internal initiative.
Overrides can also help in moments where user experience needs clarity, such as differentiating a confirmation step or visually reinforcing progression. When used selectively, overrides extend your theme. When used everywhere, they can start to fragment it. That balance is the difference between a polished, recognizable experience and something that feels inconsistent.
Begin by configuring your theme.
Themes define the global branding elements that should apply consistently across your org or Experience Cloud site, including colors, typography, and spacing. They create the visual baseline that screen flows inherit automatically.
Starting with your theme ensures that:
If your screen flow runs in Experience Cloud, consider using a Lightning Web Runtime (LWR)-based site whenever possible. LWR sites offer greater flexibility for branding and styling, which can reduce the need for flow-level overrides later.
Think of your theme as the starting point for your design system. It sets the tone and structure before any flow-specific refinements are introduced. With that foundation in place, you can evaluate whether individual screens require additional distinction.
Learn more:
After configuring your theme, use the Preview Style dropdown in Flow Builder to see how your selected theme applies to your screens.
If you haven’t tried Theme Preview yet, consider this your nudge. You can see how your theme applies directly within Flow Builder before reaching for overrides.
This step is about observation. Before introducing overrides, understand what the flow already communicates. As you review the preview, evaluate two things: usability and brand alignment.
From a usability standpoint:
From a branding standpoint:
At this stage, resist the urge to adjust anything. The goal is simply to identify where clarity or alignment could be improved.
Tip: Selecting a theme from the Preview Style dropdown only changes the preview experience. It does not alter the theme applied at runtime. You can safely explore different themes without impacting live configuration.
Learn more:
Once you’ve identified potential gaps, decide what adjustments are actually necessary. If it doesn’t solve a problem, it’s probably just glitter—and glitter is hard to clean up later.
Document or outline:
Ask yourself:
If similar adjustments are needed across multiple screens, revisit the theme instead. Overrides are best used for intentional, targeted refinements.
By defining your changes before applying them, you reduce the risk of layering overrides without a clear purpose.
Learn more:
With your design decisions defined, apply screen-level overrides when you need to adjust elements that belong to the screen itself rather than a specific component.
Screen-level overrides affect:
These changes apply at the screen level and do not cascade to individual components within the screen.
In a two-screen flow, Screen 1 collects input and Screen 2 confirms submission. By default, both screens use the same primary button styling for Next and Finish, making progression and completion visually similar.
To reinforce completion, you adjust the footer button styling so the Next button on Screen 1 uses a more neutral treatment, while the Finish button on Screen 2 uses a more visually prominent treatment to signal final submission.
Because footer buttons are screen-level elements, this adjustment is made at the screen level. The result is a clearer distinction between progressing and completing the flow.
Use component-level overrides when you need to adjust a specific component instance within a screen. Component-level overrides apply only to the selected component. They do not affect other components on the screen or across the flow.
On a second screen, you display a summary of previously entered information at the top, followed by additional input fields beneath it.
If the summary section appears visually similar to the editable fields, users may hesitate or attempt to interact with content that isn’t meant to be changed.
By adjusting the background color of the summary section to match the standard read-only field styling, you clearly distinguish review-only content from fields that require input. This maintains visual consistency while improving scanability.
Overrides apply to different parts of a component depending on the component type. For container-style components, such as Section, styling applies to the entire container. For input-based components like Text or Address, styling applies to the input area. Label styling continues to follow the applied theme and isn’t currently customizable by overrides.
Screen and component overrides give you precision, while themes give you consistency. When you use them together, you can refine specific sections of a screen without sacrificing a cohesive experience.
The most effective flows are not the most customized ones. They’re the ones where hierarchy is clear, branding feels intentional, and users understand what to do at a glance. Overrides should enhance the structure already established by your theme, not compete with it.
Good design is rarely about adding more. It’s about knowing where to add just enough.
Styling overrides give you precision, while themes give you consistency. Start with your foundation, evaluate what needs refinement, then apply overrides only where they add clarity or reinforce meaning.
The goal isn’t more customization—it’s better design. When screen and component overrides are used with intention, flows feel cohesive, recognizable, and easy to maintain.
The flexibility introduced in Spring ’26 is only the beginning.
In an upcoming release, styling overrides will also be available for custom screen components. This means that if you build your own components, you’ll be able to extend the same override capabilities to them.
We’ll also continue expanding override support to additional standard components. As styling capabilities grow, the same principles apply: Start with your theme, evaluate intentionally, and apply overrides where they improve clarity or alignment.
After years of staring at bright screens, managing eye fatigue, and cleaning your blue-light glasses, we’re thrilled to finally launch dark mode (beta) to Starter orgs in Winter ’26. We know you’ve been asking for this feature for years, so we needed to do it right and ensure the experience would be stable across our […]
Editor’s note: This post was updated on August 18, 2025, with the latest information and resources. In Winter ’25, Salesforce released multi-column sort as a beta. More than 3,000 customers opted into the new feature and feedback has been positive. In Winter ’26, multi-column sort will be generally available! Learn about list view multi-column sort […]
Winter ’25 is almost here! Learn more about Conditional Field Formatting and check out Be Release Ready to discover more resources to help you prepare for Winter ’25. The challenge with configuring visual indicators today Creating custom visual indicators to call attention to key fields is a common Salesforce configuration requirement. Visual indicators make it […]
