> For the complete documentation index, see [llms.txt](https://docs.akenza.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.akenza.io/device-management/managing-a-workspace/custom-fields.md). # Custom fields Store your own structured information on devices, such as a serial number, an installation date, or a location. **Custom fields** add your own information to a device, alongside the data it sends. A serial number, the date a battery was last replaced, the room a sensor hangs in, the contact responsible for it: none of this arrives in an uplink, but all of it is needed to run a fleet. A custom field is defined once for the [workspace](/device-management/managing-a-workspace.md) and can then be filled in on any device in it. The definition holds the name, the type, and, for text and number fields, the values that may be chosen. ## Field types

Type	Use it for
Text	Anything written, such as a serial number, an asset tag from another system, or a responsible team.
Number	Values you want to compare or sort, such as a floor number or an installation height.
Date	Points in time, such as commissioning, last maintenance, or warranty expiry.
GPS coordinates	A fixed position for a device that does not report one itself.
JSON	Structured information that does not fit the other types, for example a block of configuration carried over from another system.

Pick the narrowest type that fits. A date stored as text cannot be sorted sensibly, and a number stored as text will not compare the way you expect. ### Select options For **Text** and **Number** fields you can define the values that may be chosen, which turns the field into a list instead of free input. This is what keeps a fleet consistent: `Floor 1`, `floor 1`, and `1st floor` are three different values when they are typed by hand, and one value when they are picked from a list. Options are added, edited, and removed in the custom field management page, and a field can be marked as **required** so that a value has to be supplied rather than left empty. ## Adding a custom field to a device A custom field can be set while the device is being created, with *+ Add Custom Field*. An existing field can be selected, or a new one created on the spot.

Adding a custom field during device creation — Custom fields during device creation

The field types available for a custom field — The available field types

The same fields can be set later on the device itself, so nothing has to be decided at creation time. ## Managing custom fields for the workspace **Custom Fields** in the workspace settings lists every field defined in the workspace. From there you can create a field, edit an existing one including its select options, and import a set of fields at once. Definitions and values are separate things: editing a definition changes the field for every device that uses it, while a value belongs to the one device it is set on. ### Importing definitions A set of custom fields can be imported from a CSV file with these columns:

Column	What it holds
`name`	The field name as it appears on devices.
`description`	An optional explanation of what belongs in the field.
`type`	`STRING`, `NUMBER`, `DATE`, `GPS`, or `JSON`.
`required`	`true` or `false`.
`selectOptions`	The permitted values for a text or number field, one per line inside the cell. Leave empty for free input.

{% file src="/files/X9FXBu5e4EofkBn9ZgXV" %} {% hint style="info" %} This imports the **definitions**. To fill in **values** across many devices, use the asset inventory: custom field values are one of the properties supported by [bulk edit](/device-management/create-new-device/asset-bulk-import.md), and they can also be set per device during a [bulk import](/device-management/create-new-device/asset-bulk-import.md) of devices. {% endhint %} ## Where custom fields show up * **In the asset inventory**, as columns you can show alongside the built-in ones. * **In filters**, so you can list every device sharing a value, for example all sensors on one floor or every device due for a battery change. * **In outputs**, template custom field values as part of the events sent by an output connector. {% hint style="info" %} Custom fields describe a single device. To group devices so that rules and filters can address them together, use [tags](/device-management/managing-a-workspace/tags.md). To model how devices relate to a building, its floors, and its rooms, use the [Data Fusion Layer](/data-fusion-layer/data-fusion-layer.md). {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.akenza.io/device-management/managing-a-workspace/custom-fields.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.