Content types

Content types define a set of fields that can contain all kinds of data (for example building names, addresses, dates, numbers, images etc.).

You can think of them as tables in an Excel sheet where the content type defines the table and its columns and the items are stored as table rows. Content types are defined in a JSON document, which can be loaded into iCL Portal and iCL Designer to make use of them.

tip

For an in depth understanding of content types and -items, please read the knowledge base articles here

Note: You can download our demo workbook 💾 for this section and follow along. The definition of the content type can be found here 💾

Import content types into the workbook

To import a content type into the workbook for further use, you can right-click on the Workbook Explorer folder 'Content Types' to select the .json file from the respective folder by 'Import'.

Using content types in checklists

A content type is included in the checklist via fields. To do this, select a field and change the 'Control' type to 'Content Item'. Then you can select one of the imported content types in the field below.

Content types - Options

The following options are available for the content type:

Option	Description
Filter	If the field is not readonly, it allows users to open a list of items that they can choose from. The filter can be used to reduce the amount of available items. E.g. You could restrict the list of available buildings to those with a specific zip code.
Automatic creation	Allows data fed to the content type during an inspection to be stored as a new record in the iCL Portal.
Automatic updates	Allows you to change existing data of the content type and update these changes in the iCL Portal.
Autofill	A Content Type is usually automatically entered into the Content Type field when it is selected at the beginning of the inspection. With Autofill you can disable this default procedure to manually select the content type at a later time.
in first checklist only	If enabled, the autofill settings will only affect the first checklist within an inspection. If the user creates additional ones, autofill will be disabled for these.
Enable Auditing	As with any other field, this option stores a timestamp and the currently active user when this field is changed. This is a general option and does not relate directly to content types.

Content types - Mappings

Content types contain any number of fields that can be filled with data. When a content type is imported into a workbook, its fields can be mapped to fields within the checklist. That way, upon completion of the inspection, the fields of the content item will be updated using the data of the corresponding checklist fields. Note that every field that is mandatory is marked with an asterisk (*) at the end.

The next two sections are about binding data of content items to and from checklists.

Content types - Blockly Scripts

Mappings are just blockly scripts that allow you to bind the value of any checklist field to a particular field of a content item. If this data is also to be displayed in the workbook, fields must be created for display and linked to the mapping fields of the content type.

In the following example, we mapped the content items fields to some fields in the checklist. Note, that we did map different types of fields: buildingname is just a text field, whereas image is an image, zip_code is numeric and built is a field of type date! Also note, that the mapping for zip_code looks a bit different: Because it maps to an option field (drop down) in the checklist, you can choose whether you would like to retrieve that fields value or title.

Now, if you also want to display the value of a content item's field in the checklist, you need to bind it to the scripted answer of some checklist field. Typically you will re-use the same checklist fields that you already bound to the content item using its mappings. As an example, we show you how we load the buildingname field into the checklist

To do that, simply drag and drop the content field building into the editor of scripted answer.

The fallback content to display on prerendering

As you can see, you need to manually specify the name of the content items's field that you want to get. In this case there are five fields to choose from: (Please ignore IsDeleted - we'll cover that one later)

When are mappings evaluated?

It is important to understand, that the content item mappings are not live. What do we mean by 'live'? Essentially, this means, that whenever a content field is changed - for example: The user picks some building for the field building - then all scripted answers depending on it will be evaluated. Therefore, the text field building_name will immediately show the name of the selected building.

However, when the user then changes the text field building_name in the checklist, this does not immediately update the name of the building. This may be confusing. After all, we specified in our mapping that the buildings field buildingname is bound to that text field in the checklist.

Instead, only when the inspection is completed, all mappings in the checklists are evaluated and used to update the building (if 'automatic updates' is enabled), or create a new one if it does not yet exist (and 'automatic creation' is enabled).

This is an important feature, as it allows you to track exactly which items were updated/created during an inspection. Also, it allows for cancelling an inspection at any time without leaving intermediary and incorrect changes to content items.

The special field 'IsDeleted'

If you recall, the mapping field 'IsDeleted' was mentioned briefly above, but not explained. This is a built-in field that every content type has. It essentially gives you the chance to permanently delete an item from the system. For example: You may discover, that a building has been demolished. Then you can map a boolean field (e.g. a yes-no checklist field) to it, so that your users can cause this item to be deleted.

Note, that in case you would rather like to hide the item from further inspections, you should rather introduce some custom field (e.g. 'isarchived') and filter those items from your checklist. That way, you can still see those items with their inspections in the system, while hiding them from your inspectors.

Content Types - Repeat Content Items with Checklists / Chapters / Headlines

It is possible to repeat checklists, chapters and headlines with content item data. If you have a standard content type for inspections and a related defect content type, you are able to create a list of defects related to a specific entry of the standard content type for inspections. Like listing defects of a certain Building.

If you want to list a list of objects with all its contained defects, the level of hierarchy is the chapter for the object, and the headline for its defects.

In the properties window of a chapter or headline you gain content type related settings when selecting the 'is Repeatable' property.

In the Checklist property window you are able to select the Repeat for property directly. This option is required to create repeatable content items.

In this section you can add content item references to the checklist, chapter or headline. This requires a standard content type as well as a defect content type, which has set a relation to the standard content type. Both Content Types have to be added as question nodes of the type 'Content Item' in the repeated tree as well.

Repeat for - Inspected Items

If the property 'repeat for' is set to Inspected Items, it is required to add the standard content item here, where object data or inspectable data is stored.

Property	Description
Repeat for	Inspected Item: requires a normal content type (BuiltInTypeId: 0)
of type	This property accepts all content types that can be inspected. E.g. you cannot reference a defect content type here.
context field	Sets the field in which the content item for each repeated instance will be stored. This value is automatically set.

Repeat for - Related Items

If the property 'repeat for' is set to Related Items, it is required to add a content type with relations to a parent content type.

Property	Description
Repeat for	Related Item: requires a content type with a a field of the built-in type ParentContentItemid and a relationship to an inspectable content type.
of type	This property accepts the content type itself, as long as he is already set as a question node in one of the descending headlines.
context field	Sets the field in which the content item for each repeated instance will be stored. This value is automatically set.
query	Defines filters and ordering for the related items. One filter is required, and it defines the parent content item for which the related items should be repeated.

Blockly Query

With the Related Items setting there also comes a blockly query with it.

You are able to filter and sort your defect content item data via different blocks.