Item types
An item type is the schema for one kind of thing you track, such as computers, software licenses, services, or cost centers. Each instance of the type is a single item. In other database architectures, an item type would correspond to a table, and each item would correspond to a row.Creating an item type
The Create item type dialog
- Go to Databases->New item type to create a new item type.
- Enter a name for the item type.
- Optionally choose a parent item type. Use a parent when several related types share a base set of fields. For instance, setting “Asset” as the parent of “Computer”, “Phone”, and “Monitor” means you can query “all assets” without joining three tables, while each child still carries its own type-specific fields.
- Optionally set the item type as a relationship (edge) type
- Add additional fields as needed
Parent-child hierarchy
Child types inherit every field from their parent type. For instance, add a field to “Asset” and it appears on “Computer”, “Phone” and “Monitor” automatically. Child types can add their own fields as well. Multiple levels of nesting are supported, but deep hierarchies can make schema changes difficult to understand. One or two levels of inheritance should handle most real-world models.Fields
Fields are typed columns on an item type. The available field types:The key field
Every item type designates one field as the key field. The key is what Serval uses to deduplicate when syncing from external sources. If a sync sees the same key twice, it updates the existing item instead of creating a duplicate. Pick a stable and unique identifier from the source system. For example:- Computer: serial number, MDM device ID, or asset tag
- User: email address or IdP user ID
- Software License: license key
- Service: service code or CMDB
sys_id
The name field
The name field is the display label shown in the list view, ticket attachments, workflow output, and the context graph. Pick whatever a human would call the item: hostname for computers, full name for users, “Adobe Creative Cloud, Marketing seat” for licenses.Item reference field
Two item types can be linked with an item reference field. A computer can carry an “owner” field pointing at a user. A service can have a “depends_on” field pointing at other services. An incident can have an “affected_asset” field pointing at a computer. Item references are first-class: queries traverse them, and the context graph visualizes the result.Relationship (edge) types
When a relationship is many-to-many and carries information of its own (such as a software license assigned to a user with a start date, a seat ID, and an approver), an item reference field on one side isn’t enough. Set the item type as an Relationship (edge) type: an item type that exists to connect two others. An edge type has exactly two single-valued item reference fields, one for each endpoint. The field names become the direction labels in the context graph (assigned_to reads as the forward direction; the reverse is auto-generated).
Use an edge type when:
- The relationship is many-to-many
- The relationship carries fields of its own (dates, seat IDs, justifications, costs)
- You want both endpoints queryable by relationship
Reference data schemas
Reference data schemas hold lookup values used by other item types: department codes, cost centers, region IDs, and ServiceNow reference rows. They’re queryable like any other item but don’t show up in asset-style browse experiences. Use a reference data schema when:- The data is a lookup, not a primary asset
- You expect to reference it from other item types via an item reference field
- You don’t want it cluttering the main asset list
Schema changes
Serval supports adding, renaming, retyping, and deleting fields after data is in place. Most changes run as asynchronous schema migrations; you can poll the migration to track completion.Adding a field
Adding a field is the safe operation. Existing items start with the field unset. New and updated items populate it. No data conversion runs.Renaming a field
Renaming a field updates the display name and regenerates the field key from the new name. Workflow code that references the old key needs to be updated. Existing field values are untouched.Changing a field’s data type
You can retype a field after the fact. The migration runs asynchronously and converts existing values where possible. Most type changes are attempted value-by-value and fail the migration on the first unconvertible value. Common conversions and how they behave:
The following types are always blocked and can’t be converted:
If conversion fails for any row, the migration fails and the field stays at the old type. Fix the offending rows first, then retry.
Deleting a field
Deleting a field removes it from the item type and, by default, from every descendant type that inherits it.Deleting an item type
Deleting an item type also deletes all of its child types. The items themselves aren’t permanently removed. Instead, they stay hidden from queries, but are kept for audit.What’s next
Populate the schema
Connect an external source and let AI-suggested mappings handle the wiring.
Add items by hand
Add or import items through the UI and bulk CSV.
Reference from workflows and skills
Read and write items from workflow code. Surface them to the Help Desk Agent.
Permissions and history
Control who can view and edit items, and trace every field change.