Colours, fonts and logos
The detail behind the theme panel: what a colour value may look like, which fonts are available, and why a logo sometimes shows in one place and not the other. Read this when a theme value you set appears to have no effect.
Colour formats
Section titled “Colour formats”The three colour controls in the builder are native colour pickers, so anything you set there is a valid hex value. This list matters for the other way a colour reaches a form, an imported blueprint, whose theme can carry any of these as text:
| Form | Examples |
|---|---|
| Hex | #1B76D1, #fff, #ffffff80 (eight-digit hex carries transparency) |
| Colour name | white, rebeccapurple, transparent |
| Older functions | rgb(27, 118, 209), rgba(0, 0, 0, 0.5), hsl(210 100% 50%) |
| Modern functions | oklch(0.7 0.15 250), oklab(...), lab(...), lch(...), hwb(...), color(display-p3 1 0 0) |
color-mix() is not supported. Anything that is not one of the forms above is ignored rather than rendered, and the form falls back to the packaged default, so a colour that seems to do nothing is worth checking against this table first.
Rounded corners and space between fields
Section titled “Rounded corners and space between fields”Both are chosen from a named list in the builder’s theme panel and in the Admin Dashboard’s Default theme panel: Square, Subtle, Rounded, Very rounded, Pill for corners, and Compact, Comfortable, Roomy for spacing, with Theme default and Custom at the ends.
Custom takes a non-negative CSS length: 1rem, 12px, 0.5em, or 0. A negative value is refused when you save, and anything that is not a length is ignored by the renderer the same way an unreadable colour is. A stored value matching no named option opens under Custom unchanged.
Font family is chosen from a short list in the builder: system, sans-serif, serif and monospace stacks that every browser already has, plus a Custom option for a stack you have made available yourself.
Nothing in the package fetches a web font, and Lightning blocks external font services, so naming a font that is not installed on the respondent’s device quietly falls back to the default. To use your own font, serve it from a static resource in your org.
A logo is set per form, in the builder’s theme panel, as an https:// address. Anything else, such as http://, a data address, or a relative path, is ignored rather than rendered.
An external logo host has to be registered before the image will appear, in up to two separate places, and this is the most common reason a logo shows up in one place and not the other:
| Where the form renders | Governed by |
|---|---|
| The builder preview, inside Salesforce | Setup, Security, CSP Trusted Sites, with the image context enabled |
| The public form on an Experience Cloud site | That site’s own security settings, configured separately |
Because those are independent, a logo can load on the live form and stay blank in the builder, or the reverse. This is a step you have to take: a package can only pre-authorise a fixed address, never one an admin types later.
The builder says so inline rather than leaving a blank space. A well-formed https logo that fails to load is replaced with a short note naming the possibilities: a wrong address, an unreachable host, or the security setting above. The builder cannot tell those apart, because they all surface the same way, so check the address first.
Hosting the image inside your own org avoids the question entirely. A static resource, or a file on the site itself, is also the more robust choice: an external host can move the asset, throttle it, or serve it slowly on every render.