Skip to main content

User requirement sets

docs image

User requirement sets

Managing frontend required fields

User requirements enable you to control which fields will and will not be displayed in your front end when performing certain actions, such as creating a new user or placing an order. Additionally, you can specify which fields are required, preferred, or regular.


To access this chapter, you need the UserRequirements permission. Permissions are managed from the Roles and rights chapter namely, from the functionalities card of a users role.

The chapter starts with an overview of all existing User requirement sets. You can filter based on the sets name or by organization unit(s).

User requirement set

A user requirement set in this context means a collection of standalone user requirements and the respective configuration of each.

User requirement set example

Before we go into details, here is an example of how user requirements work.

The set of requirements shown in this overview depict the following:

  • The fields we wish to request from the front end: EmailAddress, FirstName, LastName, and initials;
  • The field(s) we do not wish to request from the front end: BackendRelationID;
  • The fields that will bear a Preferred labeling on the front end will be: EmailAddress, FirstName, and LastName (preferred but not mandatory);
  • The fields that will not bear a Preferred labeling on the front end will be: initials (not preferred & not mandatory);
  • All fields are not required, hence the None value on the Required for property (all fields are not mandatory to fill).
  • The requirement initials has a supplementary configuration on the length input of 1 to 4 characters.

Creating or editing a set

Click the '+' in the top right corner to create a new set. Creating a new set works the same as editing an existing one.

First, we give our set a name and specify to which organization unit(s) it would apply.

Organization unit set

If Organization unit set was your chosen option, make use of the 'Framed magnifying glass' icon called Subsets for an overview of that sets organization units.

After clicking Create, your overview will include two more cards namely, Default user requirements which includes a set of requirements that are available out-of-the-box, and Additional custom requirement.

Each user requirement consists of a few components. Some can be edited using the Actions column 'Pencil' icon:

  1. User type
  2. Required for
  3. Preferred
  4. Visibility
  5. Supplementary configurations
User custom fields

If custom user fields are needed, check Custom fields docs on how that can be configured.

User type

Specify which user type(s) the user requirement would apply to, Employee, Customer, or both.

User type selection

A selection for this component only applies when using the Additional custom requirement card.

Required for

Required for can be set to one of the following values:

  • None
  • Create
  • Place order
  • Payment
  • All


When setting this to Create, the corresponding user requirement will be required to fill in during create user flows. Hence, a user will not be able to proceed until a value is filled-in for that user requirement. On the other hand, None would mean that the user requirement is not required, and thus optional at all times (regardless the flow).

Additional custom requirement

When it comes to making a user requirement mandatory to fill in or not, an exception from the configuration choice made in the default user requirement card can be made. To do so, you'll need to use the Additional custom requirement card.


There are two display types here:

  • Preferred: Choosing preferred will make the corresponding user requirement bear a preferred labelling on the front end. However, this does not make the user requirement a mandatory one to be filled out by the front end user.
  • Regular: Choosing regular will make the corresponding user requirement not bear any labels on the frontend, and thus optional to fill out.


Visibility specifies whether the requirement is displayed on the front end or not. The Hide checkbox (if applicable), will hide the requirement in the front end.

Supplementary configurations

Depending on the user requirement, supplementary configurations may apply. An important example for this is the Phone number user requirement. A field called Shipping method will pop up if the Required for component on the Phone number user requirement is set to Place order. The combination allows you to make the Phone number a requirement when an order is being placed using a specific shipping method.

Another simple example would be having a Maximum length and/or Minimum length on a user requirement, like Initials.

Additional user requirement

There could be instances where you'd want an additional custom configuration on a certain default user requirement. This is where this card comes into play.


Let's take the default user requirement called initials. In the default card example given, we've set this on Required for None (meaning not required / optional), but we would like to have it required only if it's a create flow. In such scenario, using the additional user requirement card would be a valid choice. Add the Initials user requirement using the cards corresponding '+' icon, and specify the value of Required for as Create. By doing so, the user requirement becomes required to fill in during create flows only. Hence, will remain None (optional) for the other flows.

Scripting on user requirements

You can use a script to make user requirements. This can be done for the following required for options:

  • Create
  • Place Order
  • Payment

To attach a script simply tick the Script checkbox. Once ticked, a dropdown will be presented with applicable results. The results here are based on whether a script exists or not. Check sample scripts here and more about scripting in general here.