Types

Types are the classification categories used throughout Tagnet. They give structure and visual identity to your items, locations, devices, and transactions. Each type has a name, icon, and color that appear consistently across the application. Each kind of type is managed next to the things it classifies: an Item Types tab on the Items page, a Transaction Types tab on the Inventory page, and a Types tab on the Locations and Devices pages.

Overview

Tagnet uses four type systems, each on the page of the things it classifies.

Type	Where	Purpose	Example Types
Item Types	Items page, Item Types tab	Classify inventory items by nature	Asset, Consumable, Product, Raw Material
Location Types	Locations page, Types tab	Classify locations by function	Warehouse, Room, Shelf, Zone, Vehicle
Device Types	Devices page, Types tab	Classify devices by business role	Dock Portal, Handheld Scanner, Conveyor Reader
Transaction Types	Inventory page, Transaction Types tab	Classify inventory movements	Add, Move, Consume, Transfer, Adjust

Each tab has its own address (/items/types, /inventory/transaction-types, /locations/types, /devices/types), so you can bookmark or share a link that lands directly on one. Links to the old Types page redirect to the right tab.

From these tabs you can:

• Create, edit, and copy types in each category
• Assign custom icons and colors for visual identification
• Enable quantity tracking for item types
• Configure identifier strategies (Instance ID and Tag ID) for item types
• Define transaction codes for workflow and API integration
• View usage counts to understand type adoption

Permissions

Permission	What It Allows
View Types	See all type definitions across all tabs
Manage Types	Create, edit, copy, and delete types

Access scopes control which types a user can manage. Types in the system scope are visible to all but can only be edited by users assigned to it. By default, new types are created in the shared system scope with no prompt; if your deployment enables the Scoping > Site Catalog policy (disabled by default, see Policies), the Access Scope field on each type instead offers an Availability choice so individual sites can maintain their own types. See Access Scopes for the full explanation.

Choosing an Icon and Color

Every type's create and edit page has an Icon and color field that shows the type's chip as it will appear across the application. Click Change to pick both in one place:

• The chip at the top previews your choice as you go.
• Search the icons, or scroll the grid, and click an icon to select it.
• Click a color swatch, or click More… for the full color picker (spectrum, grid, and palette views, or a hex value).
• Click Apply to keep your choice, or Cancel to leave the type as it was.

Quick Import uses the same picker when you set up the item types an import creates.

Item Types

Item types classify catalog items and their inventory instances. They determine the icon and color shown on item chips throughout the application.

Fields

Field	Description	Required
Name	Display name	Yes
Code	Optional stable identifier that links this item type to your external systems	No
Description	Purpose or usage notes	No
Icon	Material Design icon for visual identification	Yes
Color	Color for chips and badges	Yes
Tracks Quantity	Enable quantity tracking for items of this type	No
Instance ID Strategy	How instance identifiers are generated for inventory items of this type	Yes
Sequence Generator	A specific instance ID generator to pin, or Scope default to resolve per inventory item's scope (shown when strategy is Sequence Generator)	Conditional
Tag ID Strategy	How RFID Tag IDs (EPCs) are obtained for items of this type	Yes
Tag ID Sequence Generator	A specific Tag ID generator to pin, or Scope default to resolve per inventory item's scope (shown when strategy is Sequence Generator)	Conditional
Access Scope	Visibility and management control	Yes

Item Type Code

The Code field is an optional, stable identifier you can use to tie a Tagnet item type to a reference in your own systems. For example, a lumber supplier might use grading codes like AD (Air Dried) or GR (Green), and a manufacturer might use family codes like RAW-STEEL or FIN-GOODS.

The code complements Name rather than replacing it: Name is the human-friendly label shown throughout Tagnet and can be freely reworded, while the code is a compact, machine-friendly value meant to stay stable for integrations. Like names, codes must be unique across your entire Tagnet instance.

Formatting rules:

• Optional. Item types without a code still work normally; they are referenced by their internal numeric ID.
• Globally unique, case-insensitive: ad and AD are treated as the same code and entering a duplicate is rejected.
• Stored and displayed in uppercase. You can type in lowercase; Tagnet uppercases it on save.
• Allowed characters: letters, digits, and the separators hyphen, underscore, dot, colon ( - _ . : ). No spaces or slashes.
• Maximum 100 characters.

Codes are mutable. You can add a code to an existing item type, correct a typo, or clear it by leaving the field blank. That said, treat renaming an established code like renaming a key: any external systems that reference the old value will stop finding the item type by code, and any item-creation calls that use itemTypeCode will need the new value.

The edit form shows a live validation message if you enter invalid characters or a code that is already in use. The Code column on the Item Types grid, and the item type detail page, show the code when one is set.

Note: Copying an item type does not copy its Code, since codes must be unique. Assign a new code to the copy if you need one.

Quantity Tracking

When Tracks Quantity is enabled for an item type:

• Inventory items of this type display a quantity field
• Quantities can be set during creation and updated during edits
• The Qty column becomes available in the inventory grid
• Decimal values are supported (e.g., 50.5 liters)

This is useful for consumables, materials, and bulk items where you need to track how much remains rather than just whether the item is present.

Instance ID Strategy

The instance ID strategy controls how individual inventory items created from catalog items of this type receive their unique instance identifiers.

Strategy	Behavior	Best For
Auto GUID	System generates a unique identifier automatically (default)	Items where the ID does not need to be human-readable
Supplied	The identifier is provided explicitly at the time the inventory item is created (e.g., a serial number)	Serialized assets with existing external identifiers
Sequence Generator	A configured sequence generator mints the next value automatically (e.g., "ASSET-0001")	Items that need readable, sequential identifiers

When you select Sequence Generator, a second field appears with Scope default as the first option, followed by any generators available in the item type's own access scope. Leaving the selection on Scope default means each inventory item resolves its generator from the default generator of its own access scope (the site it's being created in), not the item type's scope. This is what lets one shared item type mint different, per-site sequences: pin a specific generator instead only when every inventory item of this type, no matter which scope it's created in, should share the exact same sequence. There is no fallback to the system scope: if a scope has no default generator and the type is left on Scope default, creating an inventory item there fails until you configure one. For details on creating generators and setting scope defaults, see the Sequence Generators guide.

Note: All catalog items of this type share the same strategy. To use different strategies for different product families, create separate item types.

Note: The Sequence Generator strategy is selectable even before any generator exists in scope. If you leave the selection on Scope default, make sure every scope that will create items of this type has its own default generator before anyone commissions or creates inventory there.

Tag ID Strategy

The Tag ID strategy controls how RFID Tag IDs (EPCs, the 96-bit identifiers written to physical tags) are obtained when commissioning inventory items of this type.

Strategy	Behavior	Best For
Supplied	The Tag ID is provided by the caller at commission time (default)	Deployments where tags are pre-encoded or EPCs come from an external source
Sequence Generator	A Tag ID sequence generator mints the next EPC automatically	Deployments where Tagnet encodes and manages all RFID tags
Sequence Generator (supplied Tag ID wins)	Tagnet mints from the generator, unless the caller provides a Tag ID for that row	One item type printed by two processes that source their EPCs differently

When you select Sequence Generator for the Tag ID Strategy, a Tag ID Sequence Generator dropdown appears with Scope default as the first option. Pin a specific generator configured with a Tag ID scheme (such as Tag Partitioned or Tag Signed) to have every item of this type mint from that one sequence, or leave it on Scope default to resolve, at commission or creation time, the default Tag ID generator of the inventory item's own scope. As with Instance ID, there is no fallback to the system scope: the target scope must have its own default Tag ID generator or commissioning/creation fails.

When one item type is printed by two processes

Sequence Generator (supplied Tag ID wins) exists for the case where the same item type is commissioned by two different processes that disagree about who owns the EPC. A typical split: one group prints purchased supplies with EPCs it computes itself (embedding its own location codes, batch numbers, and counter), while another group does not care about EPC content and just wants the site's generated value. Rather than splitting a meaningful item type in two, set the type to this strategy and let each row decide: a row that sends a tagId keeps it, a row that sends none is minted from the same generator chain the plain Sequence Generator strategy uses.

This strategy is deliberately permissive, so choose it rather than defaulting to it. Under it, a row that meant to supply a Tag ID but omitted it is minted instead of failed, which puts a Tagnet-generated EPC on a label that was supposed to carry your own encoding. To rule that out, have the integration send tagIdSource on each row: "supplied" or "generate". It never changes the outcome, it only fails the row when the actual source is not the one declared. Set it once in each process's payload template and neither process can silently take the other's path. See the Commissioning reliability guide.

If both streams run against the same item type, keep their EPC spaces disjoint: Tagnet's partitioned Tag IDs always begin with the header 54, so an externally computed encoding that avoids that header can never collide with a generated one. Should a supplied value collide anyway (with an active or a retired tag), that row fails inline with "EPC already exists" and the rest of the batch still commissions.

For details on Tag ID schemes and how EPCs are structured, see the Sequence Generators guide.

For Integrations

If you connect Tagnet to an external system that already has its own type codes (a grading system, a parts classification scheme, etc.), item type codes give you a stable way to reference types without relying on Tagnet's internal numeric IDs.

Look up an item type by code

GET /api/v1/types/items/by-code/{code}

Returns the full item type record for the given code. The lookup is case-insensitive: ad and AD both resolve to the same type.

Set or change a code

The create, update, and upsert-by-name endpoints for item types all accept code. On an update or upsert, a value sets or renames the code (rejected with a conflict if another item type already uses it), an empty string clears it, and omitting the field leaves the existing code unchanged.

Note: See the Items guide for how item type codes let integrations create items with itemTypeCode instead of looking up itemTypeId.

Location Types

Location types classify locations in your hierarchy, making the location tree visually scannable by assigning distinct icons and colors to different kinds of spaces.

A location type's page shows how many locations use it; click that card to open the location tree filtered to the type.

Fields

Field	Description	Required
Name	Display name (e.g., Warehouse, Room, Shelf)	Yes
Description	Purpose or usage notes	No
Icon	Material Design icon	Yes
Color	Color for location chips	Yes
Access Scope	Visibility and management control	Yes

Device Types

Device types classify RFID readers and other devices by their business function, helping you organize and filter devices by purpose rather than hardware model. They are managed from the Types tab of the Devices page, and created from that page's Add menu.

Fields

Field	Description	Required
Name	Display name (e.g., Dock Portal, Handheld Scanner)	Yes
Description	Purpose or usage notes	No
Icon	Material Design icon	Yes
Color	Color for device type chips	Yes
Access Scope	Visibility and management control	Yes

Transaction Types

Transaction types classify inventory movements, providing a clear vocabulary for what happened when an item changed location. Each transaction type includes a short code used by workflows and APIs.

Fields

Field	Description	Required
Name	Display name (e.g., Add, Move, Consume)	Yes
Code	Short identifier (e.g., "ADD", "MOVE", "CONSUME")	Yes
Description	Purpose or usage notes	No
Removes from inventory (close-out)	When enabled, using this type closes the item out of live inventory and sets its state to Closed. Use for terminal events such as Ship, Consume, or Decommission. Returns are automatic when an item is moved back into a location.	No
Icon	Material Design icon	Yes
Color	Color for transaction chips	Yes
Access Scope	Visibility and management control	Yes

Transaction codes are used in workflow actions, movement rules, and API integrations to specify which type of transaction to create. For a full explanation of how close-out types affect item lifecycle, see Inventory Item Lifecycle.

Changing or Deleting a Transaction Type's Code

Unlike an item type's Code, a transaction type's Code is required, and workflow actions, movement rules, and API calls reference a transaction type by that code rather than by name. Nothing updates those references automatically, so Tagnet shows a confirmation before you rename a code or delete the type that holds it, explaining that anything still pointing at the old code will stop matching until you update it (or a type with that code exists again).

Important: The code ADD carries extra weight: Quick Import and the Map to Item quick action in Live Reads both depend on a transaction type with code ADD existing. If you rename or delete the type currently holding that code, the confirmation names this dependency specifically, and both features stop working until a transaction type with code ADD exists again.

Common Actions

All four type categories share the same actions. Create is in the page's Add menu (for example, Add then Item Type on the Items page); Details, Edit, Copy, and Delete are available from each row's actions menu (clicking anywhere else on the row also opens Details):

Action	Description
Create	Open a blank create page for a new type: name, icon, color, and the fields specific to that category. From the Add menu of the page the type belongs to.
Details	Open the type's own page: full configuration, usage, and audit history at a stable, shareable URL (e.g., /item-types/42). Users with View Audit Logs see this page as Overview and Change history tabs; the Change history tab lists that type's changes newest first. See Change History.
Edit	Open an edit page pre-filled with the type's current values. The edit page has a section navigation rail and a sticky footer showing whether you have unsaved changes.
Copy	Open the create page pre-filled from an existing type, with "(Copy)" appended to the name. Adjust anything that needs to differ, then save it as a new type.
Delete	Remove a type (disabled if the type is in use).

Deletion Rules

A type can only be deleted if nothing references it. The grid shows a usage count for each type, and the delete option is disabled with a tooltip showing how many entities use it. Deleting a transaction type additionally warns about any code references; see Changing or Deleting a Transaction Type's Code above.

Search

Each types tab has its own search bar that filters by name and description (plus code for transaction types). The search and the column you sorted by are remembered for the session.

Best Practices

• Use descriptive names: Type names appear throughout the application, so choose names that are immediately clear to all users.
• Choose distinct icons and colors: Visual differentiation helps users quickly identify types in grids, trees, and chips.
• Set identifier strategies before creating items: The Instance ID and Tag ID strategies on an Item Type apply to all items of that type. Decide your identification approach (Auto GUID, Supplied, or Sequence Generator) before adding catalog items so that inventory items are commissioned consistently from the start.
• Create separate item types for different identification approaches: If one product family uses serial-number entry and another uses auto-generated sequences, give each its own item type. All items of a type share its strategy. The one exception is Tag IDs: when the split is between two processes printing the same material rather than between two product families, use Sequence Generator (supplied Tag ID wins) instead of duplicating a type whose code already means something.
• Use Scope default to share one item type across sites: Instead of creating a separate item type per site just to get different identifier sequences, leave the Sequence Generator selection on Scope default and give each site its own default generator. See Shared Catalog with Scope Default.
• Assign codes where you integrate: If an external system already has its own identifiers for your item types (grading codes, family codes, classification schemes), set those as the Code in Tagnet. Integrators can then create items with itemTypeCode instead of tracking Tagnet's internal item type IDs.
• Treat code renames carefully: Once an external system has stored an item type code, changing it breaks any lookup or item-creation call that relied on the old value. Establish a naming convention early and communicate any renames to integration owners.
• Plan transaction types early: Transaction types are referenced by movement rules, workflows, and the API. Establish a clear vocabulary (Add, Move, Receive, Transfer, Ship, Consume, Decommission) before configuring automation.
• Mark close-out types correctly: Enable the "Removes from inventory" toggle on any type that represents a terminal event (Ship, Consume, Scrap, Decommission). This keeps lifecycle states accurate and dashboard on-hand counts correct.
• Enable quantity tracking intentionally: Only enable it for item types where tracking amounts matters (consumables, materials). For discrete assets, leave it disabled.
• Use access scopes for multi-tenant setups: Create scope-specific types when different teams or divisions need different classifications.