Item types & fields

Item types define the kinds of records your projects work with — Requirement, Test Case, Risk, and any others your process needs — and the fields each one carries. This is the foundation everything else builds on: get the structure right here and the rest of the platform follows it.

This area is the true foundation of the platform, because every record’s structure, validation, and behavior flows from its item type. Defining types carefully is how you guarantee that the fields a regulator expects are actually present and governed — that a risk record captures severity and probability, that a requirement carries the attributes your framework demands — rather than left to whoever creates the record to remember. Get the item types right and consistency follows automatically across every project; get them wrong and no amount of downstream diligence fully compensates.

Fields on a type

Each item type has a set of fields. Core fields are built in; custom fields are ones you add to capture what your domain requires. For each field you set its data type — text, number, date, picklist, user, and the rest — the control used to edit it, a stable API ID for integration, and whether it’s required. Fields can be grouped into categories so a complex type stays organized rather than presenting a wall of inputs.

The admin side of authoring

This is the configuration behind the authoring experience: when someone fills in a requirement, the fields they see and the rules they’re held to are the ones defined here. The user-facing view of working with these fields is covered in Item types & fields in the Requirements section.

Why it matters

Because every record’s structure flows from its item type, defining types carefully is how you make data consistent across a project and across the organization — and how you ensure the fields a regulator expects are present and governed. Picklist fields draw their options from Picklists, and how records move is governed by Workflows.