All About Forms and Validations


In every project forms and validations play an important role. We want to avoid invalid data inputs and teach users to enter valid data in a specific field.

Let’s take the example of a field phone. The phone number is one of the things you don’t want to change when a package is out for delivery. To keep it valid, we need to apply validations to our phone fields on all forms on the site. And the best way to do this is to describe all our phone fields in XML form, provided by the SFCC.

The XML form contains all the data which require to describe and validate one form field (type, label, error messages, validations, and others) in most cases.

In this post, we will discuss on expert advice form provided in the inquiry section. It is shown on the homepage.

The current expert advice form contains four fields name, email, phone, and message. Let’s start by making an XML form. Forms are located in the base cartridge provided by SFRA which allows you to look at them for some reference about field definitions.  

We have to make the same folder structure in our cartridge also. So, add some code in the XML file to describe our fields.

Now we need a basic form that requires a field, and then we can use that fields in isml and server-side js.

Some of the fields are mandatory in the form, which you have to provide them. I will explain just a few fields which are more important than others.

  • Formed – The name of the field which is used to access it
  • Type – A field type which is we are going to use string and boolean types
  • Mandatory – if there is no value, mark the field invalid
  • Label –  Used to show a message beside the input field.

There are two types of validation for form fields we can use. In the first type, we can apply standard validations like min and max length, mandatory, etc. Those validations will use error labels from attributes missing-error, parse-error, range-error, and value-error.

And in the second type of form and field validations-custom validation java-scripts. For example, a valid email is mandatory otherwise the form is not submitted and it shows an error alert message.

To do something like validation, an attribute is introduced. It must contain a path to the validation script and one parameter in the function call. You have to create a custom object in the business manager to store custom attributes in it.

It is always the best approach to have front-end validation. Since we are passing on back-end validation here.

Preparing Controller

We have to write a controller to render our form template. Also form, the code will need to have an action endpoint passed from the controller.

Therefore two properties are pushed to viewData. They are called forms and formActions

The expert-advice form is loaded from the user session and cleared to prevent storing data when the storefront form is submitted. SFCC stores submitted data into custom objects


Once the form is declared, the controller passes it to the template. This is when we need to use it.

Starting out from homePage.isml, include your template(file e.g expertAdvice) in homePage.isml


Every project needs static labels that are translated into the correct locale. All translations are stored in key/value pairs in .properties files in SFRA.

XML forms field label is loading a translation from by using a label field as the key. For our expert advice form, we have several translations and they are added to

Alright, now we have prepared an expert advice form to be shown to a user on the home page. I won’t focus on styling, and making it too pretty, I would rather like make it fully functional.

Thanks for reading!

About the author

Shivani Mulekar
By Shivani Mulekar