> ## Documentation Index
> Fetch the complete documentation index at: https://www.docusnap.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Data Model

> How a type is built, how a field label points to a property in the schema, and which types are shipped.

Every asset in Docusnap365 has a type, and the type determines which data it can
carry and how that data is structured. 98 types are shipped, plus the types and
fields you create yourself. The schema behind the interface follows four
definitions per type — what the user sees is under
[Data Captured](/docs/en/assets/systems).

## What a type consists of

A type consists of four definitions side by side:

| Definition | What it holds |
| - | - |
| `registry` | the label in both languages, the icon and the segment key |
| `dataDefinition` | the properties of the type with their data type and, where one applies, a format |
| `viewDefinition` | the structure of the detail page: group › area › section › field |
| `enumDefinition` | the named value lists that individual fields point to |

73 of the 98 types carry a `viewDefinition`. The rest have no structured view —
they hold data but no detail page of their own; *Software*, *Software Product*
and the seven integration types are such cases.

## Identifier and inheritance

Every type carries an identifier made of a prefix and a name:
`typedef::windows`, `typedef::proxmoxLxc`, `typedef::integrationSftp`. It is
stable and language-independent; the label is neither.

Below it lies a second level. Every shipped type builds on a base definition of
the same name — `typedef::windows` on `basedef::windows` — and every base
definition in turn goes back to `basedef::object`. The export covers the
shipped level; the base definitions themselves are not part of it.

## From the label to the field

A field on the detail page carries its label in both languages and, next to it,
the property its value comes from. That is the path from what somebody sees to
what you query:

| Level | Windows example |
| - | - |
| Group | *Configuration* |
| Area | *Overview* |
| Section | *OS & Identity* |
| Field | *OS Architecture* |
| Property | `osArchitecture` |

A field also states how its value is to be read — as text, integer, decimal,
yes/no value, point in time, data volume, duration, frequency or network speed.
If it points to a value list, that list is named next to it: *License Status*
carries the property `licenseStatus` and the list `LicenseStatus`.

Fields can be hidden out of the box. They then stand in the definition but not in
the view — *Active User* on the type *Windows* is one of them. Showing and hiding
is done under [Adjusting the Data Model](/docs/en/settings/data-model).

## Value lists

Each type carries the value lists its own fields point to; across all types there
are 241 different ones. Every entry holds three things: a key, a technical name
and the label in both languages.

Example for the integration types:

| Key | Name | Label |
| - | - | - |
| `-1` | `Unset` | *Unset* |
| `0` | `CSV` | *CSV* |
| `1` | `JSON` | *JSON* |
| `2` | `XML` | *XML* |
| `4` | `SOAP` | *SOAP* |
| `5` | `EDIFACT` | *EDIFACT* |
| `6` | `SqlDump` | *SQL Dump* |
| `7` | `Other` | *Other* |

<Note>
  The keys have gaps — `3` is missing in the example. Rely on the key, not on the
  position in the list.
</Note>

## The field level

The 73 views carry some 11,100 fields between them. Which fields a type
carries is shown by the interface itself under Administration › *Data Model*
› *Types and Fields* in the tab *Fields* — in one list, with standard fields
and custom fields side by side.

Custom fields do not change the shipped type. They sit next to it as a type
extension: delete the extension and the custom fields are gone while the type
remains — see [Adjusting the Data Model](/docs/en/settings/data-model).

## Technical names of custom fields

As with the shipped types, the label of a custom field points to a technical
name. Docusnap365 derives it from the *Display Name (German)* when the field is
created:

* All letters are lowercased, umlauts are transliterated (ä → ae, ö → oe,
  ü → ue, ß → ss).
* All other characters separate words; at the start and the end they are
  dropped.
* The words are joined in camel case.
* The prefix of your subscription is put in front: six lowercase letters or digits, the
  first character from `a` to `f`.

“Anzahl Kerne” thus becomes `anzahlKerne`, and with the prefix, for example,
`f71378AnzahlKerne`. The prefix keeps custom fields apart from the properties of
the shipped types: a custom field “Name” does not coincide with the name of the
asset.

If the derivation yields a technical name that is already taken, Docusnap365
appends a number without a message (`f71378AnzahlKerne2`). On creation, only
the display name is checked. The interface does not show the technical name
anywhere.

## Number fields

A custom field has two field types for numbers. *Number* holds numbers with
decimal places, *Integer* only whole numbers. Fields created as number fields
before 18 September 2026 carry *Integer*; this field type cannot be chosen for a
new field. In the list in the tab *Fields* both are shown as *Number* — they can
only be told apart in the dialog *Edit Field*.

## The shipped types

A type is addressed by its identifier: it stays stable, the label can change.

| Label | Identifier |
| - | - |
| *(S)FTP* | `typedef::integrationSftp` |
| *Access Point* | `typedef::accessPoint` |
| *Active Directory* | `typedef::activeDirectory` |
| *Active Directory Group* | `typedef::activeDirectoryGroup` |
| *Active Directory User* | `typedef::activeDirectoryUser` |
| *Android Device* | `typedef::androidDevice` |
| *Application* | `typedef::app` |
| *Business Service* | `typedef::businessService` |
| *Camera* | `typedef::camera` |
| *Chassis* | `typedef::chassis` |
| *CRM* | `typedef::crm` |
| *Department* | `typedef::department` |
| *DFS Domain* | `typedef::dfsDomain` |
| *DFS Standalone* | `typedef::dfsStandalone` |
| *DHCP* | `typedef::dhcp` |
| *DNS* | `typedef::dns` |
| *E-Mail* | `typedef::integrationEmail` |
| *Entra ID* | `typedef::entraId` |
| *Entra ID Contact* | `typedef::entraIdContact` |
| *Entra ID Device* | `typedef::entraIdDevice` |
| *Entra ID Group* | `typedef::entraIdGroup` |
| *Entra ID User* | `typedef::entraIdUser` |
| *Exchange Online* | `typedef::exchangeOnline` |
| *Filer* | `typedef::filer` |
| *Firewall* | `typedef::firewall` |
| *Generic* | `typedef::generic` |
| *Hyper-V Server* | `typedef::hypervServer` |
| *Hyper-V Switch* | `typedef::hypervSwitch` |
| *Hyper-V VM* | `typedef::hypervVm` |
| *iLO* | `typedef::ilo` |
| *Information* | `typedef::information` |
| *Intune* | `typedef::intune` |
| *Intune Device* | `typedef::intuneDevice` |
| *IP Phone* | `typedef::voIP` |
| *iPad* | `typedef::iPad` |
| *iPhone* | `typedef::iPhone` |
| *Linux* | `typedef::linux` |
| *Load Balancer* | `typedef::loadBalancer` |
| *macOS* | `typedef::macOS` |
| *MariaDB Database* | `typedef::mariaDbDatabase` |
| *MariaDB Server* | `typedef::mariaDbServer` |
| *Meraki* | `typedef::meraki` |
| *Microsoft 365* | `typedef::m365` |
| *Microsoft Identity* | `typedef::microsoftIdentity` |
| *Microsoft Teams* | `typedef::teams` |
| *Monitor* | `typedef::monitor` |
| *MySQL Database* | `typedef::mySqlDatabase` |
| *MySQL Server* | `typedef::mySqlServer` |
| *Network System* | `typedef::networkSystem` |
| *Network System Topology* | `typedef::networkSystemTopology` |
| *Network System Topology V Switch* | `typedef::networkSystemTopologyVSwitch` |
| *NFS* | `typedef::integrationNfs` |
| *NTFS Server* | `typedef::ntfsServer` |
| *Nutanix* | `typedef::nutanixCluster` |
| *Nutanix Host* | `typedef::nutanixHost` |
| *Nutanix Virtual Switch* | `typedef::nutanixVirtualSwitch` |
| *Nutanix VM* | `typedef::nutanixVM` |
| *OneDrive* | `typedef::oneDrive` |
| *Oracle* | `typedef::oracle` |
| *Person* | `typedef::person` |
| *Printer* | `typedef::printer` |
| *Process* | `typedef::process` |
| *Proxmox* | `typedef::proxmoxCluster` |
| *Proxmox Bridge* | `typedef::proxmoxBridge` |
| *Proxmox Linux Container* | `typedef::proxmoxLxc` |
| *Proxmox Node* | `typedef::proxmoxNode` |
| *Proxmox VM* | `typedef::proxmoxQemu` |
| *REST API* | `typedef::integrationRestApi` |
| *Router* | `typedef::router` |
| *Samsung* | `typedef::samsung` |
| *Samsung Galaxy Tab* | `typedef::samsungGalaxyTab` |
| *SharePoint Online* | `typedef::sharepointOnline` |
| *SMB* | `typedef::integrationSmb` |
| *Software* | `typedef::software` |
| *Software Product* | `typedef::softwareProduct` |
| *SQL* | `typedef::integrationSql` |
| *SQL Server Database* | `typedef::msSqlDatabase` |
| *SQL Server Instance* | `typedef::msSqlServer` |
| *Storage Hardware* | `typedef::storageHardware` |
| *Storage Volume* | `typedef::storageVolume` |
| *Switch* | `typedef::switch` |
| *Tape* | `typedef::tape` |
| *Unknown* | `typedef::unTyped` |
| *Upload* | `typedef::integrationUpload` |
| *UPS* | `typedef::ups` |
| *User* | `typedef::user` |
| *Veeam* | `typedef::veeam` |
| *VMware* | `typedef::vmware` |
| *VMware Distributed vSwitch* | `typedef::vmwareDVSwitch` |
| *VMware Host* | `typedef::vmwareHost` |
| *VMware VM* | `typedef::vmwareVm` |
| *VMware vSwitch* | `typedef::vmwareVSwitch` |
| *Windows* | `typedef::windows` |
| *Windows Surface* | `typedef::windowsSurface` |
| *XenServer* | `typedef::xenServer` |
| *XenServer Host* | `typedef::xenServerHost` |
| *XenServer Network* | `typedef::xenServerNetwork` |
| *XenServer VM* | `typedef::xenServerVm` |

## Related

Which data the individual scans write into these types is under
[Data Captured](/docs/en/assets/systems). How you extend the model with your own types
and fields is under [Adjusting the Data Model](/docs/en/settings/data-model).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.