Internals

How OmniScript styling actually works

Once you understand the four moving parts (runtime, theme, load order, and token cascade), almost every styling surprise becomes predictable.

Two runtimes, one set of class names (mostly)

OmniStudio currently ships in two forms, and the DOM tells you which one you have:

Salesforce is moving orgs to the standard runtime, where designers and components are built into the platform rather than installed as a package. The familiar class names mostly survive, but screens get reorganized between releases, so verify field locations in your org rather than trusting screenshots in old blog posts.

Two themes, two stylesheet fields

Every LWC OmniScript runs in either the Lightning (SLDS) theme or the Newport theme. The generated component tag embeds the theme name, and a via-slds class on generated cards confirms SLDS. The theme decides which Setup field your stylesheet goes in:

• Lightning theme: Custom Lightning Stylesheet File Name
• Newport theme: Custom Newport Stylesheet File Name

Both fields expect a static resource name only. No .css extension, no link tag, no quotes, no path. The resource must be one plain CSS file. Newport is its own CSS framework (originally from Vlocity) and is mostly used for OmniOut and off-platform deployments; inside Experience Cloud, Lightning is the common choice.

CSS load order and who wins

On a portal page, styles arrive in roughly this order, and later or more specific wins:

1. SLDS base styles and the site's branding set (the colors you picked in Experience Builder's Theme panel).
2. Site-level custom CSS: the Theme CSS editor or Head Markup.
3. Component bundle CSS, including the OmniScript stylesheet static resource, which loads with the component wherever it renders.
4. Inline styles written by the FlexCard and OmniScript designers onto individual elements: icon fills, label colors, per-element backgrounds.

The design token cascade

The Lightning Design System Design Tokens field in OmniScript Setup takes raw declarations, one per line, like --lwc-spacingMedium: 16px;. Three prefix families coexist in the one field, and each runtime reads only its own:

Token name conversion for the --lwc- family: take the SLDS token, remove dashes, camelCase it, replace the dollar sign with --lwc-. So $spacing-xx-small becomes --lwc-spacingXxSmall. You can see this cascade live on real portals: active navigation links carry var(--lwc-colorTextActionLabelActive, var(--dxp-g-brand-1)), exactly this fallback chain.

There is a fourth, finer level: component styling hooks like --slds-c-icon-color-background, scoped to a single component type. Useful for surgical changes once the global hooks are in place.

Shadow DOM: why LWR is different

Aura sites use synthetic shadow DOM, so CSS from Head Markup or the Theme editor can reach inside components. LWR sites use native shadow DOM: site-level CSS stops at the component boundary and never reaches OmniScript internals. On LWR, style the script through the things that travel with it (the OmniScript stylesheet and design tokens) and keep site CSS for the page shell.

Two more boundaries no CSS crosses: embedded dashboards render in an iframe (a separate document), and the Builder canvas adds its own chrome around your preview.

Selector stability: what to trust