Jeremy Davis
Jeremy Davis
Sitecore, C# and web development
Article printed from: https://blog.jermdavis.dev/posts/2025/radio-buttons-saas-forms

Fun with Radio Buttons in Sitecore's SaaS forms

A work-around for an unexpected bug with how forms are rendered

Published 24 August 2025

I was doing some investigation into moving some Experience Forms UI over to the new SaaS Forms in XM Cloud recently, and bumped into an interesting issue. If you're looking to make use of this new tool you may find this an interesting read:

The issue url copied!

I spent a bit of time in the new form designer replicating the basics of a contact form, and all looked OK:

The design view of a form with some intro text, two Radio Button choices and a text field. It is correctly displayed

Most of the form in question doesn't matter - the important bit was that there was a radio button list which does not show any sort of title above the individual options the user can choose. That lack of title isn't the default for a radio button field, however. You have to modify the default properties of the field to disable the main label:

The properties checkbox for 'Hide main label' on the radio button field

And that all looks fine until you swap over to the "preview" tab, to look at what your form will be when it's injected into a website. That's not right:

The labels for the individual radio buttons have vanished

As well as there being no main label on the radio button list, each of the radio buttons appears to have lost its label too...

A hacky fix url copied!

If you look at the page DOM via browser dev tools, the labels are still there - but they've been set to display: none in the CSS by activating that "hide the main label" option:

The browser DOM showing the label still exists, but is hidden from display by CSS

So it seems like whatever CSS is applied by the "Hide main label" property is a bit over-enthusiastic and hides this text as well as the bit it was supposed to affect.

But that means we can work around this fairly easily with a bit of extra CSS. The SaaS forms allows you to add "Custom Styles" to your forms. The default is a visual editor for this, but you can change it to show the raw CSS by clicking the "CSS Editor" button once you've created your own custom style:

The style editor in Sitecore's SaaS forms, showing the 'css editor' button that allows changing the raw CSS

You can add in this simple style to the end of the text to restore the labels:

label.radio-field > span.form-field-label {
    display: inline;
    padding-top: 2px;
}

					

And then you have to assign the custom CSS to your form:

The settings page for a form in Sitecore's SaaS forms. Showing the 'apply style to form' button that lets you customise your form

From the Settings cog in the form editor, pick "Apply style to form" and then pick your custom style from the dropdown.

With that done, the preview will look correct again:

The fixed form, with the labels for individual radio button choices showing again

Worth noting url copied!

When you apply a custom style to a form, you get this notification shown in the settings page:

A notification saying 'Style in-use is saved as CSS code, and the changes will only be visible when seen in preview'

When I first read that I assumed it meant "you can't see your custom styles applied when you look at the design view for the form - only when you look at the preview" - and that is true.

However there's a second thing it's trying to tell you. It seems like when you apply a custom theme it is copying the data to your form, rather than making a live link. So if you go back to your custom style data and save new changes, you won't see these applied to your customised form when you refresh the preview.

You have to remove the custom styles and add them again from the settings page, in order for your preview to update with style changes. Click the "Clear style" button and then repeat the "Apply style to form" process:

The 'clear style' button which can be used to remove old styles

Conclusions url copied!

I've raised this with Sitecore Support and they've accepted it as bug reference DESIGNLIB-2819 - so if it's not fixed by the time you come to try and make forms yourself, you can cite that bug number to point out this has been a problem for a while...

↑ Back to top