> 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/tags.md). # Tags Group devices in a workspace so that rules, dashboards, filters, and bulk actions can address them together. A **tag** is a label put on devices so they can be treated as a group. Where a [custom field](/device-management/managing-a-workspace/custom-fields.md) describes one device, a tag connects many: every sensor on the first floor, every CO2 sensor, every device belonging to one customer. Using tags for grouping devices, a single [rule](/device-management/rule-engine.md) can cover all of its devices, a filter can list them, a dashboard component can aggregate and visualize data for all of the devices belonging to a tag, without anyone maintaining a list of device IDs by hand. Tags belong to the [workspace](/device-management/managing-a-workspace.md). A tag name is limited to **64 characters** and has to be unique within its workspace, so the same name can exist in another workspace without the two being related. ## Adding tags when you create a device Tags can be assigned in the device creation step. Existing tags are offered in the tag field, and typing a name that does not exist yet creates it.

Assigning tags while creating a device — Tags during device creation

## Adding tags to an existing device On the device detail page you can pick from the tags already in the workspace or create a new one. A device can carry as many tags as you need, which is what makes tags worth using: a sensor can be part of a floor, a device class, and a customer at the same time.

{% hint style="info" %} Removing a tag from a device only removes the assignment. The tag itself stays in the workspace and keeps its other devices. {% endhint %} ## Managing tags for the workspace **Tags** in the workspace settings lists every tag in the workspace, where they can be created, edited, and imported in bulk. Each tag has a name, an optional description, and a color, which is what makes it recognizable at a glance in the inventory. A set of tags can be imported from a CSV file with these columns:

Column	What it holds
`name`	The tag name, unique in the workspace and at most 64 characters.
`description`	An optional explanation of what the tag stands for.
`color`	A hex color such as `#40A9FF`.

{% file src="/files/SG1vFLHaE6YRzvj24NVS" %} ## Using tags as rule input A tag can be selected as the [input of a rule](/device-management/rule-engine/rule-input.md), which then runs for every device carrying that tag. The rule keeps up on its own: tag a newly installed sensor and it is covered, without editing the rule.

Selecting a tag as the input of a rule — A tag as rule input

{% hint style="warning" %} Devices addressed through one tag have to share a data schema, meaning the same topic and data keys. The rule logic reads a specific key from the incoming sample, so a device that structures its data differently will not produce the value the rule expects. {% endhint %} This is the practical reason to keep at least one tag per device class. A tag such as `co2` is safe as a rule input in a way that `building_a`, spanning every kind of sensor in a building, is not. ## Using tags as a dashboard data source A [dashboard](/dashboard-builder/dashboard-builder.md) component reads either from one device or from a tag. On the component's **Source** tab, set **Type** to *Tag*, pick the tag, and choose the data point to read. The component then covers every device carrying that tag, and combines their values into the figure it shows, according to the aggregation settings of the component. A trend component pointed at a tag such as `1og` and the data point `count`, aggregated by maximum, reports the peak number of people counted across that floor, regardless of how many sensors contribute to it. Two things follow from this: * **The dashboard keeps up with the fleet.** A sensor tagged after the dashboard was built is included the next time the component loads, without anyone editing the dashboard. * **The data point has to exist on every device with the tag**, for the same reason it has to for rules. A device that does not report the selected key contributes nothing to the result. ## Naming tags Tags are flat labels, with no hierarchy and no nesting, so the structure has to live in the names. A convention worth adopting: * **By device type**, for example `temperature`, `co2`, `water-meter`. These are the tags that work as rule inputs. * **By location**, for example `floor_1`, `building_a`. These are what you filter the inventory by. * **By responsibility**, for example a customer, a tenant, or the team that maintains the devices. Agree on the separator and the case before the fleet grows. `floor1` and `floor_1` are two tags, and nothing later merges them. {% hint style="info" %} Tags are for grouping. To model a building properly, with sites, floors, zones, and what each sensor measures in them, use the [Data Fusion Layer](/data-fusion-layer/data-fusion-layer.md), which carries the relationships a flat label cannot. {% 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 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/tags.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 `automate deployments from our CI pipeline` 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.