Skip to main content
Under Administration › Data Model › Types and Fields you define which types exist, which fields they carry and where they appear. That sets this area apart from Environment Data, which manages the inventory itself—here the model is defined, not the inventory.

​
How this area is organized

Data Model leads to two entries, each with its own task:
The two pages share the same data but read it separately. A change on one becomes visible on the other only when you open it again.

​
Built-in and custom types

The interface treats both kinds of type alike; what is saved differs:
A custom type that still carries assets cannot be deleted. For a custom type without assets, Delete Type? removes it irrevocably. For a built-in type you have customized, Delete Extension? instead removes only the extension with your custom fields—the type itself remains.
If no customization of a built-in type remains after saving, Docusnap365 removes the extension itself. The type then counts as unchanged again.

​
Creating a custom type

The Create Type dialog captures only the basics: a type name in German and English, an optional description, an icon and at least one navigation list item. You edit fields, lists and the preview afterward, on the new type’s other tabs.
Both Type Name (German) and Type Name (English) are required. Without an English name, the type is either missing from the English interface or shows up there in German.
A display name that is already taken is rejected, as is a name that starts with a digit or that derives the same internal identifier as an existing custom type. This dialog does not exist for built-in types—for them, only the fields path applies, see below. New types and fields can be created only after the settings for custom fields have loaded; until then, the buttons for creating them are locked. If loading fails, Types and Fields shows an error bar.
If the error bar offers no retry, the server rejected the request for lack of permission. Opening the page again does not change that.

​
Adding fields

Standard fields and custom fields sit in one shared list; a custom field can be dragged between two standard fields instead of only being appended at the end.
On a standard field, only visibility and position can be changed. Field type, label and required flag stay as the product delivers them.
A custom field carries a display name in German (required) and English, a type, an optional Required switch, and a default value: If Display Name (English) is left empty, the field appears in the English interface with its German name. A Date or Time default value in an invalid format prevents the field from being saved: clicking Create or Save in the field dialog then has no effect. The technical name of a custom field starts with a prefix. How to address it through the API is described under MCP & API › Data Model.
A new field of type Number accepts decimals; Integer cannot be selected for new fields. A custom field that still carries the earlier number type accepts no decimals: the field list shows it as Number, and only the field dialog shows the type Integer. If you select another type there, Integer can no longer be selected afterward.
Changing the type of a field whose last saved state carried a different type shows a notice that data already captured may no longer fit afterward. The notice is skipped for a newly created field with no saved state yet, and for a type that has no assets.

​
Editing selection values

For the Selection field type, you enter the values yourself: a display name in German and English per value, and whether it is the default. An empty English display name is replaced by the German one, as for the field. Exactly one value can be marked as default; a duplicate display name is rejected. The list order is the order of the selection—changeable at any time, even later.

​
Adding a field for every type

Under Shared Fields sits the row Base. A field you create there afterward applies to every type. That row carries only the Fields and Preview tabs—it is not itself a type that could be hidden or assigned to a list.

​
Visibility per type

For the selected type, the Usage tab sets three switches: ITAM and ISMS decide here whether a type takes part in the ITAM tab or the ISMS tab of the asset.
When Type Active is off, ITAM and ISMS are locked.
The Lists tab sets which navigation lists a custom type appears in.
At least one list must stay assigned. Trying to deselect the last one has no effect.

​
Preview

The Preview tab shows the layout of this type’s detail page: under General, all visible fields in their order, without values. A hidden standard field is missing there. If a type description is set, the Description section is added.

​
Visibility at a glance

The Visibility page shows Active, ITAM and ISMS for every type side by side—built-in and custom alike.
A locked row means that the visibility state of this type is not known. The same state locks the switches on the Usage tab.

​
Saving

The Fields, Usage and Lists tabs collect changes and save them only when you click Save in the tab header. Discard next to it reverts all unsaved changes of the tab. If you switch type or tab, or leave Administration, while unsaved changes exist, a prompt asks whether to discard them. If saving fails, the changes stay in the tab and can be saved again. If saving is still in progress when you leave, Save in Progress asks instead. Leave still completes the save; the changes can no longer be discarded. The Visibility page, by contrast, saves each switch immediately. If saving fails, the whole row reverts to its last saved state. Only deletion always asks for confirmation.
If the subscription’s Storage usage limit is exceeded, types, fields and visibility can only be viewed. The buttons for creating, saving, discarding and deleting are not shown, and the switches are locked.
How a type’s fields appear on the asset’s detail page is described under Assets—Basics. What a built-in type brings along in scan data is described on the pages of the Data Captured group, for example under Systems.