> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getprimo.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Custom fields
> Define your own data attributes on devices to capture company-specific information, segment your fleet, power Device Group rules, and report on the data you need.
**Availability:** Custom fields are in beta and rolling out to accounts. If you don't see them yet, the feature isn't enabled for your organization. Custom fields apply to **Devices**, **Employees**, **Orders**, and **Accessories**.
## What are custom fields?
The dashboard includes a standard set of attributes on every device — model, operating system, serial number, assigned employee, and more. **Custom fields** let you add your own attributes to capture data that isn't tracked out of the box.
A custom field is a data attribute you define yourself — for example *Department*, *Asset Tag*, *Warranty Expiry*, or *Criticality*. Once created, it behaves like any other built-in attribute: you fill in a value on each record, then view, edit, and filter on it.
## Why use them — and who they're for
Custom fields address a few common needs:
* **Track data that isn't modeled out of the box.** Capture asset tags, purchase order numbers, warranty dates, and internal cost centers.
* **Segment your fleet.** Group and filter devices by your own categories (for example, *Department* or *Criticality*) instead of only by built-in attributes.
* **Power Device Group rules.** Use a custom field as a condition so the right devices automatically fall into the right [Device Group](/mdm/device-groups) and receive the right profiles and controls.
* **Report on your own data.** Surface your own attributes alongside standard device data.
They're built for:
* **IT admins** who need the fleet to reflect their organization's real structure and policies.
* **Asset managers** who track ownership, warranty, and lifecycle data per device.
## Key concepts
### Field
A **field** is the attribute you define. Each field has:
* A **name** (for example, *Department*).
* A **type** that determines what kind of value it holds (see below).
* An **applies to** scope that determines which records can hold a value for it.
### Field types
Choose a type when you create a field. The type can't be changed afterward, so pick the one that matches the data you're capturing.
| Type | Use this when… | Predefined options? |
| ---------------------------------- | ------------------------------------------------------------------------------------------------ | ------------------- |
| **Text** | You need free-form text, like a note or an asset tag. | No |
| **Number** | You're capturing a numeric value, like a cost or a count. | No |
| **Date** | You're recording a date, like a warranty expiry. | No |
| **URL** | You're storing a link, like a vendor or ticket page. | No |
| **Checkbox (yes/no)** | The answer is yes or no, like *Under warranty*. | No |
| **Select (one choice)** | There's a fixed list and each device picks exactly one, like *Criticality: Low / Medium / High*. | Yes |
| **Multi-select (several choices)** | There's a fixed list and a device can have more than one, like *Installed peripherals*. | Yes |
**Options** are the predefined choices you set up for **Select** and **Multi-select** fields. The other types don't use options — the value is typed in directly.
### Applies to
**Applies to** defines which records a field can hold a value on. Custom fields apply to **Devices**, **Employees**, **Orders**, and **Accessories**.
You can **expand** what a field applies to later, but you can't **shrink** it. Once a field is available on a type of record, that availability stays — so set scope thoughtfully.
### Values
A **value** is the data entered for a field on a specific record — for example, the *Department* field with the value *Finance* on a particular laptop. Each record holds its own value for each field that applies to it.
## Use custom fields
### Create a field
Navigate to **Settings** > **Custom Fields** and review the existing fields in the table.
Click **Add field** and give the field a **name**.
Select a **type** (see [Field types](#field-types)).
If you chose **Select** or **Multi-select**, add the **options** users can pick from.
Set what the field **applies to** (Devices, Employees, Orders, or Accessories).
Save the field.
### Set values
Once a field exists, fill in its value on each record (device, employee, order, or accessory):
Open a device, employee, order, or accessory to bring up its detail panel (the drawer).
Find your custom field among the record's attributes.
Enter or pick the value inline and save.
### Edit a field
Refine a field after it's created. From **Settings** > **Custom Fields**, open the field to:
* **Rename the field.**
* **Add options** to a Select or Multi-select field.
* **Rename options.** Renaming an option does **not** lose data on devices already using it — those devices keep their value, now shown under the new label.
* **Widen what it applies to** (for example, extend it to a new record type once that's supported).
You can't change a field's **type**, and you can't **narrow** what it applies to.
### Filter and segment
Custom fields make your fleet easier to slice:
* **Filter the Devices list** by a custom field to find a subset of devices.
* **Target Device Groups** using a custom field as a rule, so matching devices are automatically included and receive the right profiles and controls.
**Current limit:** Filtering and Device Group targeting work with **Select**, **Multi-select**, and **Checkbox (yes/no)** fields. Text, Number, Date, and URL fields can't be used as filters yet.
### Delete a field
When you no longer need a field, delete it from **Settings** > **Custom Fields**. You can delete a field only when it has **no related entities** (see below).
#### Related entities
A **related entity** is anything that depends on a field. A field gains related entities when you use it in:
* a **saved (custom) view** that filters the Devices list by the field, or
* a **Device Group** that uses the field as a filter.
While a field has related entities, you **can't delete it** — the dashboard protects the views and groups that rely on it. A **Related entities** indicator shows exactly what's referencing the field. To delete it, first remove the field from those views and Device Group filters; once it has no related entities, the delete becomes available.
## What you can and can't do today
| You can | You can't (today) |
| ------------------------------------------------------------------------------ | ---------------------------------------------------------------------- |
| Create Text, Number, Date, URL, Checkbox, Select, and Multi-select fields | Change a field's type after it's created |
| Give two fields the same name (names don't have to be unique) | Delete a field while a saved view or Device Group filter still uses it |
| Delete a field that has no related entities | Delete a single option — remove the whole field instead if needed |
| Add and rename options on Select / Multi-select fields | Filter by Text, Date, Number, or URL fields yet |
| Filter and target Device Groups with Select, Multi-select, and Checkbox fields | Narrow what a field applies to |
| Widen what a field applies to | — |
| Apply fields to Devices, Employees, Orders, and Accessories | — |
| Edit values inline on a record | — |
## Availability and access
**Admins with access to Settings** manage custom fields under **Settings** > **Custom Fields**.
The feature is **in beta and rolling out** to accounts. If you don't see it in your Settings, the feature isn't enabled for your organization yet — contact your Primo representative.