Fields are single data storing units that build up Content Types - in other words: field are attributes of content. A single field represents a single chunk of information, such as a name or a date. Fields are mapped to repository data slots in the storage layer, and can be displayed and accessed through APIs.

A field is a data storing building block of a content. However, it not only stores data, but also carries metadata and configuration settings. Metadata includes attributes like Title and Description, configuration includes attributes like Compulsory and ReadOnly.

Field types

There are numerous field types defined in the base system. Different field types store different types of data and have different configuration. A Number field for example stores a number and - among others - MaxValue property can be configured to limit the maximum value stored, whereas a ShortText Field stores text data and has a MaxLength configuration property that can be set to limit the maximum allowed number of characters stored in the Field.

Binary Fieldfor binary data
Boolean Fieldfor storing a boolean value (true or false)
Choice Fielda multi-purpose field used to allow the user to choose one or more options
Color Fieldfor storing color code in hex
Currency Fieldfor storing a number value as value in specified currency
DateTime Fieldstores a date and a time value
HyperLink Fieldstores a link to the required content or webpage
Image Fieldhandle an image attached to the content
Integer Field
LongText Fieldfor storing text without length restrictions
Number Fieldfor storing a whole number with value
Reference Fieldfor defining references to other content
ShortText Fieldfor storing short strings
Special system types-
ApprovingMode Fieldfor storing the approval mode
InheritableApprovingMode Fieldfor storing the inherited approval mode
VersioningMode Fieldfor storing the versioning mode
InheritableVersioningMode Fieldfor storing the inherited versioning mode
Lock Fieldfor storing whether a content is locked or not
NodeType Fieldfor storing the content type
Password Fieldfor storing passwords
Version Fieldfor storing the current version number

Field setting

Fields can be configured to behave different ways. This is controlled by their configuration - or with other name: their field setting. The field setting of a field contains properties that define the behavior of the field - for example configured as read only or required to fill. The field setting can be adjusted with its field definition.

Field definition

As fields build up content, the set of contained fields are defined when content types are defined. The content type definition (CTD) for different types holds the field definition information besides a couple of type-related configuration settings. When defining a content type the contained fields can be defined in the CTD with XML fragments describing the type of the field, metadata and configuration:

<Field name="MyField" type="ShortText">
<DisplayName>My field</DisplayName>
<Description>Field to contain custom data</Description>
<Bind property="AnotherField" />
<DefaultValue>lorem ipsum</DefaultValue>
nameName of the field. Required, should be unique in a content type.
typeShort name of the field type. This or handler is required. (see the list of field types above)
handlerFully qualified type name of field handler class. This or handler is required.
DisplayNameDisplayed name of the field.
DescriptionDescription of the field.
BindName of the storage property the field is bound to.
IndexingIndexing settings of the field.
ReadOnlyIndicates if the field is read-only.
CompulsoryIndicates if the field is required to fill.
OutputMethodDefines the field output type (Default, Raw, Text, Html)
DefaultValueDefault value of the field.
VisibleBrowseIndicates if the field is visible in auto-generated browse view.
VisibleEditIndicates if the field is visible in auto-generated edit view (while a content is edited).
VisibleNewIndicates if the field is visible in auto-generated new view (while a content is created).
FieldIndexDefines order of field in auto-generated views.
ControlHintDefault field control name. Used by the mapper in control libs like sn-controls-react.

Search in fields

For every content the field values can be indexed so that when searched for a value the corresponding content will appear in the result set. It is also possible to search in fields by explicitly defining them. The way a specific field of a content is indexed is defined in the field definition.


When the content is saved the input field data falls under validation according to the field settings. This includes non-empty value check for required fields and some field setting-dependent checks. An Integer field for example validates input data against data-type check - the entered value should be an integer value - and also checks whether input data falls between the range of MinValue and MaxValue as given in the field definition in the content type's CTD.

Fields on the ui

Each repository has a content model, a schema that represents the content types you create. This schema is fully available to the client through the REST API. Using this schema it is possible to auto-generate the ui since it contains all the necessary information (field type, validations, etc). Can be a good starting point for this to check the sn-controls-react client library that contains field controls for all the built-in field types and a mapper that manage how (with which field control) the specific field types should be displayed on the ui.