IT and Capital Asset Tracking Playbook
Part of: Use-Case Playbooks — four end-to-end plans for the most common Tagnet deployments
This playbook sets up tracking for IT and capital assets: laptops, monitors, servers, network gear, tools, and other serialized equipment that lives in buildings and rooms for years. Each asset carries one RFID tag. Readers at the places assets enter, leave, and are stored keep the register current, and a workflow tells you when something leaves a building without clearance.
The outcome of IT and capital asset tracking
When this deployment works you have:
- A living asset register. Every tagged asset has a current building and room, a lifecycle state, and a history of every move. Search finds an asset by serial number or asset tag, and the filter drawer narrows by assignee or warranty date.
- A receiving-to-retirement lifecycle. An asset is New when registered, Active once placed in a location, and Closed when decommissioned. Returned or redeployed assets simply become Active again. See Inventory Item Lifecycle.
- An alert when assets leave. A reader at each building exit moves an asset to an off-premises location and can notify IT security when the asset was not cleared to leave.
- Capital value by place. With a unit cost on each catalog item, the inventory slices report total value by building, room, and item type.
- An audit trail. Every move is a transaction, and every configuration change is in Change History.
What it does not do: Tagnet is not a service desk or a CMDB. It keeps the physical truth (what and where) and can exchange data with your asset system through the REST API. Readers placed only at exits and key rooms cannot see a laptop move between two rooms that have no reader, so those moves are recorded another way (see the reader placement section).
How to model IT and capital asset tracking
Modeling decisions at a glance
| Decision | Recommendation | Why |
|---|---|---|
| Item types | Asset for laptops, monitors, and phones; Equipment for servers and network gear. Catalog one item per model | Item types decide identifiers and quantity. Models are items, units are inventory instances |
| Track quantity | Off | Each tagged asset is one unit with its own serial number |
| Locations | Campus, then building, then floor, then room. Add Data Center and Rack where needed | Matches the IT hierarchy in the Locations guide |
| Instance ID | Supplied (serial number or existing asset tag) when you tag an installed base; Instance Typed when Tagnet issues IDs | Typed IDs such as LAPTOP-0001234-7 show the category at a glance |
| Tag ID | Supplied for tags you stick on existing assets; Tag Partitioned when Tagnet mints EPCs; Tag Signed for high-value assets where authenticity matters | See Sequence Generators |
| Custom fields | Serial number, asset tag, assigned to, purchase date, purchase order, warranty expiration, condition, cleared to leave | The facts your IT team searches by |
Locations
Model the places people actually name. Add a few locations that are not rooms, because they describe an asset's status: spares, out for repair, off premises, and disposal.
Main Campus (Site, Inventory: Not Allowed)
Building A (Building, Inventory: Not Allowed)
Floor 1 (Floor, Inventory: Not Allowed)
Lobby (Room)
IT Receiving (Room)
Room 114 (Room)
Floor 2 ...
Data Center (Data Center, Inventory: Not Allowed)
Rack 12 (Rack)
IT Spares (Storage Area)
Out for Repair (In Transit)
Off Premises (In Transit) code OFFSITE
Containers (campus, building, floor) are set to Not Allowed so assets are always recorded in a room, rack, or named status location. Give locations Codes that match your facilities or asset system. If your campuses are managed by separate teams, make each one a site scope; a move between campuses then crosses scopes, which the Cross-Scope Transfer policy decides (see Workflows and alerts).
Instance IDs and tag IDs
- Tagging an installed base. Your assets already have serial numbers or asset tags and you are about to stick tags on them. Use Supplied for the Instance ID (the existing identifier) and for the Tag ID (the EPC on the tag you apply). Both are loaded in one pass with Quick Import, below.
- Issuing new IDs. For new purchases, Instance Typed embeds a category prefix and a check digit (
LAPTOP-0001234-7,MONITOR-0000456-2). Staff see the category without scanning, and the check digit rejects typing mistakes. The generator guide lists IT asset prefixes such as LAPTOP, MONITOR, DOCK, and PHONE. For heavy manual entry, Instance with Check Digit is the simpler alternative. - Minted tags. Tag Partitioned gives each tag a readable scope and category. Tag Signed adds a salted checksum that only your system can produce, which suits high-value capital assets where a forged or cloned tag is a concern.
See Types for the strategy settings and Sequence Generators for the recommended scheme per use case.
Custom fields
| Field | Level | Type | Notes |
|---|---|---|---|
| Serial number | Inventory | String | Indexed and Global Search, so a pasted serial finds the asset. Skip it if the serial is the Instance ID |
| Asset tag | Inventory | String | Indexed and Global Search |
| Assigned to | Inventory | String | Indexed |
| Purchase date | Inventory | Date | Indexed |
| Purchase order | Inventory | String | Indexed and Global Search |
| Warranty expiration | Inventory | Date | Indexed, to filter assets expiring this quarter |
| Condition | Inventory | Select | In service, Spare, In repair, Retired |
| Cleared to leave | Inventory | Boolean | Drives the exit alert below |
| Manufacturer, model | Item | String | Same for every unit of a model |
Set the Unit Cost on each catalog item so value totals appear in the inventory slices. See Custom Fields and Items.
Loading your existing register
Export your asset register to a spreadsheet and load it with Quick Import: one row per asset with Item Id, Item Description, Item Type, Instance Id, Location as a path such as Main Campus / Building A / Room 114, and Tag Id once tags are applied. Extra columns become custom fields. The wizard lets you review item types, locations, and fields before anything is created, and an import with a location records an Add transaction for each asset. Tag assets in batches, then import each batch.
Reader placement for IT asset tracking
Instrument the places where the register is most likely to go wrong, not every room.
| Where | Recipe | Read point | Why |
|---|---|---|---|
| IT receiving and imaging bench | Workstation or verification point | The IT Receiving room (a place) | New and returning assets are placed the moment they are put on the bench |
| Building exits and the loading dock | Start from Dock door with a trigger when you have a door sensor, otherwise Drive-through portal | The building (a threshold) | Direction is worked out from where the asset is recorded, so one reader serves both ways |
| Spares closet or locked cage | Cabinet or shelf, triggered audit | The storage location (a place) | A door contact starts one clean read per opening |
| Server room entrance | Same reader setup as building exits, but its own device type | The data center (a threshold) | Not a building exit: with the exit readers' type, the exit workflow would send a server leaving the room to Off Premises and alert security. Give it a copy of Workflow 2 for its own type, with leaving going to a status location such as IT Spares, arriving going to IT Receiving for racking, and no security alert |
No recipe covers a staff entrance, so the exit starting points above are just that. Tune on real passes with a laptop bag, a cart, and a person carrying a monitor. Lower the transmit power until the read zone ends at the door, and expect to adjust the quiet period for people who pause at the threshold. Laptops and servers have metal cases, so test tags made for use on metal before ordering in volume.
Moves between two rooms that have no reader are not seen. Record them with the Move action on the asset, with a call to the REST API from your asset system, or by adding a reader at the doors where it matters. This is why exits and receiving are the first places to instrument: the leakage you care about happens there.
Workflows and alerts for IT asset tracking
Workflow 1: receive at the bench
| Part | Setting |
|---|---|
| FROM | a device where Device group is IT Receiving |
| Action 1, Move Inventory | Target: Read point's location. Transaction type: Receive |
An asset already in IT Receiving is left alone, and one coming back from repair or from off premises is placed there and becomes Active again.
Workflow 2: building exit
Place the exit readers' read point at the building. The building is the threshold: "within" the read point means anywhere inside it.
| Part | Setting |
|---|---|
| FROM | a device where Device type is the type you gave your exit readers |
| Action 1, Move Inventory (leaving) | Tag condition Within read point is true. Target: Specific location, Off Premises. Transaction type: Transfer |
| Action 2, Move Inventory (arriving) | No tag conditions. Target: Specific location, the Lobby. Transaction type: Receive |
| Action 3, Notification | Action tag conditions Cleared to leave is not true, Movement result is Moved, and To location code is OFFSITE. Target IT security by user or scope |
Action 2 takes whatever action 1 did not handle, because a tag that one Move Inventory action handled is skipped by the next. Do not write the arriving action as "not within": an asset sitting in Off Premises would match neither action. The full pattern, including a warning about the Within read point condition, is in Move Inventory.
Direction comes from where Tagnet last placed the asset, not from how it crossed the door. An asset recorded inside the building is leaving when read at the exit; an asset recorded off premises is arriving. Keeping the register accurate is therefore what keeps this alert honest.
Write the condition as is not true rather than is false: an asset whose field was never set has no value, and an empty value does not equal false, so "is false" would stay silent for every asset nobody has touched. To clear a planned departure, toggle Cleared to leave to true before it goes (an Update Custom Fields action can use Toggle, or edit the field on the asset), and set it back after it returns.
Workflow 3: retire at the disposal bench
| Part | Setting |
|---|---|
| FROM | a device where Device group is Disposal Bench |
| Action 1, Move Inventory | Target: Remove from inventory. Transaction type: Decommission |
The asset becomes Closed, stays in history, and returns to Active if it is ever placed in a location again. Enable the ClosedInventory retention policy only if your audit window allows trimming old closed assets. See Inventory Item Lifecycle.
Telling your asset system
Add an HTTP Integration (durable) action after any move above, with a tag condition on Transaction type code, to post receipts, off-premises transfers, and decommissions to your asset system or CMDB. The Outbox retries until your system accepts it. See Integration Outbox.
Multiple campuses
If campuses are separate scopes, an asset moved between them is a cross-scope move. The default policy, Reject, skips the move and raises a Cross-scope movement rejected alert. If assets legitimately travel between campuses, set the Cross-Scope Transfer policy to Transfer so ownership follows the asset. See Scoping / Cross-Scope Transfer.
Alerts
- Reader offline is Critical and reaches administrators by default. A silent exit reader is a hole in the register, so also route the Devices category to IT security with Alert Routing.
- Antenna disconnected (Zebra FX) is a Warning and notifies nobody until a rule covers it. Route it to the people who maintain readers.
- See Alerts for thresholds and the full list.
What to check in the first week of IT asset tracking
- Tag a representative sample. Include a laptop, a monitor, a server, and a dock. Confirm each tag reads at the bench and at the exit. A weak read on a metal case is cheaper to find now than after tagging 2,000 assets.
- Run realistic exit tests. Carry one, then five, then a full bag through each exit. Open the scan events and check Closed by; if a group splits into two events, lengthen the quiet period.
- Check the direction logic. Carry an asset out and back in. Its Location history should show Off Premises, then the Lobby. If an asset shows the wrong direction, its recorded location was wrong before the test.
- Confirm the alert. Carry an asset whose Cleared to leave was never set through an exit and verify the notification reaches the right person once.
- Reconcile the import. Compare the Quick Import result counts with your register, and use Quick Export to diff what Tagnet holds against the source.
- Look for gaps. Filter Inventory to the New lifecycle state to find registered assets never placed, and check Live Reads for tags no inventory item carries.
- Check coverage. Group Inventory By location and look for rooms where assets pile up with no recent movement. Those are the doors worth a reader next.