System and Custom Fields


When your users sign up on your app using cidaas' registration form, they will have to provide specific information as field input values to create an account.

While some of these fields are default or system fields defined by cidaas, the others are called custom fields and can be added explicitly by you on your app's user registration form through the cidaas Admin UI.

System Fields Definition

System Fields are input fields that appear by default on your users' registration page and can be selected under Edit App > App Settings > Advance Settings > Registration Fields > Allowed Fields on the cidaas Admin UI.

These fields are defined by the cidaas Admin in the backend.

Custom Fields Definition

Custom Fields are input fields that you can explicitly create to be available on your users' registration page and can be defined under Settings > Registration Page Fields > Create Fields on the cidaas Admin UI.

System and Custom fields are useful, for example:

  1. To manage addresses (postal addresses and communication addresses).
  2. To add keys for referencing entities in the backend system like the customer number, personnel number, or contract number.
  3. To manage additional identification fields (having the data type USERNAME).

Basic Definitions and Attributes of Registration Field Setting

Entity Attribute Description
UserAccount A UserAccount represents and is mapped to a user.
SocialIdentity SocialIdentity represents a identity of an user. a user can have multiple identites
CustomField CustomFields are embedded in the UserAccount inside of customFields and is saved as <>:<>. A user can have multiple CustomFields.
Field Setting FieldSetup defines the setup of SystemField and CustomField and is uniquely defined by a fieldkey.
id The unique identifier of the database document.
fieldKey The unique identifier of the fieldSetup.
dataType Defines the datatype of a field. The datatype options are defined in the above enumeration Datatype.
internal Defines the visibility of the field which is used only for internal purposes and not visible to the users. We don't expose this field in the public registration field list. This field is editable only by the admin-user.
readOnly Marks a field as only readable and not editable by the users. Fields with readOnly:true are only editable for the admin and should be marked as readOnly in Admin-UI.
required Mandates the user to provide input to complete the registration or creation of a user account.
order Defines the order of the registration field shown in the UI.
enabled Marks a field as active.
fieldDefinition Defines the constraints for a field.
scopes Defines the scope of the registration field. An access token having scopes should match with the registration field scope, only after which the value of the field can be given in the user profile API.
localeText Defines the field in different languages for localization. It contains, for example, name, required_message, etc. which should be editable in general.
is_group Marks a field as a group and will be used to display the fieldSetup group-wise (in the UI).
parent_group_id Identifies the parent group of the field. The default parent_group_id is DEFAULT.
fieldType Defines if a field is a CUSTOM or SYSTEM field.
defaultValue Represents a default value for this field.
consent_refs Refers to the consents taken from the user during login and registration.
encrypted The fields that may not be displayed in a readable format can be defined as encrypted.
baseDatatype Defines the base datatype of a field which is used to avoid data mismatches in a field. For each data type there is a definition of base datatype (please refer to the Assignment of data type and base data type table in the next section).


The grouping of Field Setting is possible where each field is assigned to a group. The Default group can be set to type DEFAULT.

The Field Setting can be added without sub-groups only for custom fields.

However, the Field Setting can contain groups with the data type GROUPING which is used to group the Field Setting parameters which cannot be used directly for custom field.

Validation of Fields based on dataType and baseDataType

dataTypes reflect either a user interface type (like RADIO, TEXTAREA) and/or add some semantics to the data (like PASSWORD, URL, EMAIL, CONSENT) while the baseDataType is used to map the data to the data types of the programming languages and also define how data gets stored in a database like MongoDB, Elasticsearch, etc.

Please refer to the table below to understand the different dataTypes, their corresponding baseDataTypes and what they mean.

DataType BaseDataType Description
TEXT string This is a text field for which the constraints minimum and maximum text length can be defined.
NUMBER double/integer Numeric Field.
RADIO string Different values can be predefined (for a defined group) from which a value can be selected. The selected value is saved as a string.
CHECKBOX boolean Is a binary value that is stored as boolean.
PASSWORD string Is a text field for which the minimum and maximum length constraints can be defined.
DATE datetime The date for which the min and max date constraints can be defined.
URL string This is a text field for which the min and max length constraints can be defined. The incoming values need to match a url format.
EMAIL string Is a text field for which the min and max length constraints can be defined. The incoming values need to match the email format.
TEXTAREA string This is a text input field.
MOBILE string This is a text field for which the min and max lenght constraints can be defined. The incoming values need to match the mobile number format.
CONSENT boolean This is a binary value which is used to store the user's consent.
JSON_STRING string This is a text field for which the minimum and maximum text length constraints can be defined.
USERNAME string This is a text field which is used to save the unique identifiers of a user.
Array array[string] This is an array of strings without predefined values.
SELECT string This is a single value that is selected from an array of predefined ones and is saved as a string.
MULTISELECT array [string] These are multiple values that are selected from an array of predefined ones and are saved as an array of strings.

How System Fields and Custom Fields Differ?

All the fields are part of the user account domain and are described by the Field Setting. The Field Setting includes defining the following attributes for a field:

The differences between the Custom and Default Field Settings are shown in the following table:

Characteristic System Field Custom Field
Technical Entity Stored in SocialIdentity Stored in UserAccount.
Field Setting YES ("fieldType" : "SYSTEM") YES ("fieldType" : "CUSTOM")
Can be activated and deactivated. YES NO
Predefined Datatype YES (modelled in SocialIdentity). NO
Can be added. NO YES
Can be removed. NO YES
Can be individually grouped. NO YES

Handling of System Fields

System fields are filled automatically via cidaas instance creation. Each Field Setting has to be marked with fieldType: SYSTEM. This is a technical one-time execution task which includes the setup of the cidaas instance through CMI auto deployment.

Handling of Custom Fields

Add New Custom Field

On cidaas, you can add only custom fields to your application and need to contact the cidaas Admin to add or set up System Fields.

The first step is to Add Field Setting on the cidaas Admin UI to create a Custom Field.


Add Field Setting

The general flow includes Creating the Field Setting by configuring values for dataType, localText, fieldKey, etc. After creating the Field Setting, you can use it for adding new custom fields.

For this, please follow these steps.

1. Navigate to Settings > Registration Page Fields on the cidaas Admin UI Dashboard.

2. Under the Create Field page > Field Setting, provide the values for Field Key, Field Type which are mandatory.

Then, Select Scopes and Permissions (optional).

3. Configure the Locale Setting by providing the values for mandatory fields, Select Locale (language of the Registration field), Field Name Based on Locale (name of the registration field that will appear for the user), and Required Message (the message that will appear for the user).

4. Finally, provide the Minimum and Maximum length constraint values (optional) and click on Save.

The following success window appears which confirms the Field Setting creation before adding a new custom field.

Note: When you try to create a Field Setting that already exists, a notification window with the message This Registration Field already exists appears as shown below. The Field Key of a Field Setting must be unique.

Key Considerations

1. The Field Setting added cannot be easily removed since custom data could have already been assigned to various user accounts.

2. Adding the Field Setting does not automatically add and initialize any custom field in the User Account. This has to be done explicitly by Navigating to your App under Apps List > Edit App > App Settings > Advanced Settings > Registration Fields and adding the Custom Field under Allowed Fields.

You can set the Custom Field you've created as a mandatory input field on your application by selecting it from the list for Required Fields as shown below.

3. A Field Setting can only be added with a valid parent_group_id (with is_group: true and enabled: true) that is of type DEFAULT.

Validation of Custom Fields

1. You cannot add a Custom Field without providing the value for Field Type (dataType) under Field Setting.

2. For Custom Fields, you need to provide the Field Key, Field Type, and Field Name Based on Locale values. The system checks if the Field Setting you're creating is unique and only then creates it.

3. In addition to checking if the Custom Field has a Field Setting that is Enabled, the format is also validated based on if the Data Type corresponds to its relevant Base Data Type (please refer to this table).

Modifying Field Setting

You cannot edit Field Key and Field Type under Field Setting. All other fields can be edited by clicking on the Edit icon under Settings > Registration Page Fields.

Field Setting

Note: Future Scope includes making Field Type editable under Field Setting.

Locale Setting

Deleting Field Setting

Deleting a Field Setting for a Custom Field should be done carefully since custom data could already have been assigned to various user accounts.

When a Field Setting for a Custom Field is deleted, the following happens.

1. All data related to this Field Setting will be lost.

2. The Field Setup and the related Custom Field(s) with the given Field Key are deleted from all user accounts.

Deleting a Field Setting

To delete a Field Setting, please follow these steps.

1. Under Settings > Registration Fields click on the Edit icon of the Field Setting you want to delete.

2. Then, click on the delete button at the bottom of the page.

3. The following confirmation window will appear to confirm if you want to delete the field.

Clicking on Okay will display the following dialog window confirming the field deletion.

This Field Setting is also deleted under the Registration Page Fields page.

This brings us to the end of our discussion on System and Custom Fields. For any questions or assistance please visit our support page.



results matching ""

    No results matching ""