Utility Infrastructure Tracking Playbook

Part of: Use-Case Playbooks — four end-to-end plans for the most common Tagnet deployments

This playbook sets up tracking for poles, transformers, and similar equipment as they move through an energy provider's network: from a manufacturer or repair shop, through yards and service centers, in transit between them, and out to the field. Readers at yard gates and receiving docks record departures and arrivals automatically, ownership of the stock follows it from site to site, and you can see what is in transit across the whole network.

The outcome of utility infrastructure tracking

When this deployment works you have:

• Departures and arrivals without keying. A pole or transformer read at a yard portal as it leaves is moved to that site's shipped location. When it is read at another site's portal it is received into that site's yard.
• Ownership that follows the stock. Each site sees its own inventory. When stock arrives at another site, its ownership moves with it and each site keeps the history from its own time holding it.
• A network-wide view of what is in transit. Every site uses the same transit location type, so one inventory slice answers "what is on the road right now".
• Equipment history. Each pole or transformer keeps its location history, tag history, and custom fields such as manufacture date and last inspection.
• Your systems kept informed. Departures and receipts can be posted to your asset management or ERP system.

What it does not do: fixed readers cover yards, docks, and shops, not poles standing in the field. Installation and field moves are recorded by crews through the Move action, by a call from your work management system through the REST API, or by a person at a desk, not by readers on the network itself.

How to model utility infrastructure tracking

Modeling decisions at a glance

Decision	Recommendation	Why
Access scopes	One site scope per yard or service center. Catalog items, item types, and custom fields stay in the shared system scope	A move between sites is a cross-scope move; the shared catalog is what lets ownership transfer
Item types	Utility Pole and Transformer (both ship as starter types)	Separate types give separate icons, fields, and tag partitions
Track quantity	Off	Each pole and transformer is individually tagged
Locations	Per site: a Yard and a Shipped (in transit) location with the same codes at every site. In the field: region, district, substation, then structure by number	Identical codes let one workflow serve every site
Instance ID	Supplied (manufacturer serial or your pole or transformer ID), or Instance Partitioned for multi-site validation	Partitioned IDs embed the scope and a CRC-8
Tag ID	Tag Partitioned with a partition per asset class; Tag Signed for high-value transformers	Scope and class are readable from the EPC
Custom fields	Manufacture date, installation date, last inspection, treatment class, rating, condition	The record an inspector or planner needs

Locations

Two kinds of locations coexist. Yard locations are where stock sits and where fixed readers stand. Network locations are where installed equipment lives. The Locations guide gives the field-asset shape Region, District, Substation, and notes that utilities often use pole numbers such as 69A as location codes.

Yard sites, with the same layout and codes at every site:

Yard Site A                (Site, Inventory: Not Allowed)   <- portal read point is here
  Yard                     (Storage Area)  code YARD
  Shipped                  (In Transit)    code SHIP

Use the same location type (the starter In Transit type works) for every site's Shipped location. That shared type is what makes the network-wide in-transit view possible. Keep Shipped per site rather than one shared location: the departure then says which site the stock left, and a move into Shipped stays inside one scope.

Installed network, in the territory's scope:

Region North               (Area, Inventory: Not Allowed)
  District 4               (Area, Inventory: Not Allowed)
    Substation Elm         (Site or Area, Inventory: Not Allowed)
      69A                  (Zone)  code 69A

Set Inventory to Not Allowed on containers. Build large trees quickly with location paths in Quick Import, or provision them from your GIS or work management system with the by-code API in Locations.

Instance IDs and tag IDs

• Instance ID. If the manufacturer's serial number or your own pole or transformer ID is the identity people use, use Supplied. For multi-site operations that want a validated ID with the originating scope built in, Instance Partitioned produces T0001-0000001-A3: the scope, a serial, and a CRC-8.
• Tag ID. Use Tag Partitioned so every EPC carries its scope and a partition code you assign per asset class (for example 0001 for poles and 0002 for transformers). Use Tag Signed for high-value transformers where a forged or cloned tag is a concern. See Sequence Generators.
• Several sites. Leave generators on Scope default and give each site's default generator a distinct prefix or partition code, as in Shared Catalog with Scope Default. Generators in a site scope require the Scoping > Site Catalog policy (see Policies). Where one team tags everything centrally, pin a single generator on each item type.
• Tag choice. Poles are outdoors, wood or composite, and often stacked. Transformers have metal tanks. Choose tags rated for the environment and for mounting on metal, and test them on real assets before ordering at volume.

New equipment is usually tagged by the manufacturer or at the yard's receiving point. If your supplier or shop commissions tags from its own system, the commission API creates the instances and places them at a location in one call. See Integrating Tagnet with Your Systems.

Custom fields

Field	Level	Type	Notes
Manufacturer, class, height, rating	Item	String	Shared by every unit of a model
Manufacturer serial	Inventory	String	Indexed and Global Search, so a field crew can paste it
Manufacture date	Inventory	Date	Indexed
Installation date	Inventory	Date	Indexed
Last inspection	Inventory	Date	Indexed, to filter overdue units
Condition	Inventory	Select	New, In service, Repair, Scrap
Received at yard	Inventory	Date	Set by a workflow with SetToNow

See Custom Fields.

Reader placement for utility infrastructure tracking

Where	Recipe	Read point	Why
Yard gate, vehicles passing both ways	Drive-through portal	The site root (a threshold)	The recipe was written for a truck of lumber packs, which is the same problem as a trailer of poles: a large tag population per pass, with tags in the middle of the load shadowed by the ones around them
Warehouse receiving for pallets of equipment	Dock door with a trigger	The receiving location (a place)	A sensor starts a clean read per pallet
Transformer shop or test bench	Workstation or verification point	The bench location (a place)	Each unit is placed deliberately; move it to the bench, then to its next status
Storage cabinet for small parts	Cabinet or shelf	The cabinet location	Triggered audit only

For the yard gate, the portal recipe is worth reading in full. A slow, dense load usually does better with session S2 and target A, and a fast pass with tens of tags with S1 and target AB. Use Multi Tag Passage with a 1 minute quiet period so the front and back of a vehicle are one event, and a 5 minute cooldown at group scope so a vehicle that backs up is not processed twice. Watch Closed by on your first events: Max Duration means the pass was cut short.

Place the portal's read point at the site root. The portal is a threshold. An item recorded anywhere inside the site is "within" the read point, so a read means leaving. An item recorded anywhere else means arriving. Group the readers that cover one gate in one device group, and give every gate the same device type, for example Yard Portal, so one workflow can address all of them.

Workflows and alerts for utility infrastructure tracking

Before the workflow: set the cross-scope policy

Each yard is its own scope, so an arrival at a second site moves stock into a location owned by another scope. The Cross-Scope Transfer policy decides what happens. Its default, Reject, skips the arrival and raises a Cross-scope movement rejected alert. For a yard network where stock travels between sites as a matter of course, set the policy to Transfer, so the item moves and its ownership becomes the destination site's. Keep the catalog (items, item types, custom fields) in the shared scope, because a transfer is refused when an item's catalog definition belongs to a third scope. See Scoping / Cross-Scope Transfer.

Workflow 1: yard portal, depart and arrive

One shared workflow serves every site.

Part	Setting
FROM	a device where Device type is Yard Portal
FOR	every tag in the event
Action 1, Move Inventory (leaving)	Tag conditions: Within read point is true, and Location type is not In Transit. Target: Location by code in the device's scope, SHIP. Transaction type: Transfer
Action 2, Move Inventory (arriving)	No tag conditions. Target: Location by code in the device's scope, YARD. Transaction type: Receive
Action 3, Update Custom Fields	SetToNow on Received at yard, with action tag conditions Movement result is Moved and Transaction type code is RECEIVE

How the two Move Inventory actions divide the work:

• Leaving takes only items already within this site. Without the Within read point condition it would move anything read at this gate, including stock from other sites, into this site's Shipped location. The condition is required.
• Location type is not In Transit handles a load that turns around at the gate. Shipped sits inside the portal's boundary, so an item already there counts as within. Without this condition, Leaving would find it already at the Shipped target and mark it handled, and the returning load would never reach Arriving. Excluding In Transit lets it fall through and be received back into the yard.
• Arriving has no from-side condition. It takes whatever Leaving did not handle: stock arriving from another site, stock that was missed at its own departure portal, and stock returning. Writing it as "not within" would leave an item sitting in Shipped matching neither action. A tag one Move Inventory action handled is skipped by the next, so the two never fight over an item.
• The target resolves a code in the device's scope, so the same SHIP and YARD codes work at every site, and each portal sends items to its own site's locations. A code that does not exist in the device's scope is an error for that tag, so create both at every site.

See Move Inventory for the targets and the site-portal recipe.

Workflow 2: tell your systems

Add an HTTP Integration (durable) action after the moves, one action per route, each with a tag condition on Transaction type code: TRANSFER for departures and RECEIVE for arrivals. The durable delivery retries when the receiving system is unreachable. To hear about ownership changes, add a Notification or HTTP action conditioned on Scope transferred is true. See Sending data out of Tagnet and Integration Outbox.

Recording installs and field moves

Fixed readers do not cover the field. Record an installation by moving the pole or transformer to its structure location: use Move on the inventory item, Move on a mapped row in Live Reads, or a REST API call from your work management system with the structure's location code. Use a Move transaction type that makes sense for your reports. If the structure is in a different scope from the yard, the move is cross-scope and follows the same policy.

Alerts

• Reader offline is Critical and reaches administrators by default. A dead portal means departures and arrivals are not recorded, so route the Devices category to each yard's supervisors with Alert Routing.
• Antenna disconnected (Zebra FX) is a Warning and notifies nobody until a rule covers it. On a portal with four antennas, one lost cable shadows part of every pass.
• Cross-scope movement rejected means the policy is on Reject, or an item's catalog definition is not shared. Route the Inventory category to inventory control.
• If you post to other systems, route the Integration Outbox alerts to the integration owner. See Alerts.

What to check in the first week of utility infrastructure tracking

1. Drive a tagged test load through each portal in both directions. Leaving should write a Transfer into Shipped; arriving at another site should write a Receive into its Yard. The item's transaction history shows a Transferred badge on the cross-scope move.
2. Turn a vehicle around at a gate. A tagged load that has been moved to Shipped, then backs in through the same gate, should be received back into the Yard. If it stays in Shipped, check the Location type condition on the leaving action.
3. Check the codes. Open each site and confirm YARD and SHIP exist. A missing code shows up as an error on that tag in the workflow's run.
4. Check the device type. If a portal read produces no workflow run at all, the portal's device type does not match the workflow's FROM, and a miss on FROM records nothing by design. Confirm every portal has the Yard Portal type.
5. Compare counts. Open the scan events from a test pass and compare Tags with the physical count. Missing tags in the middle of a load mean shadowing; revisit the session choice in the portal recipe.
6. View the network in transit. Open the Inventory list grouped By location type and open the In Transit row to see everything shipped and not yet received across all sites. See Inventory Slices.
7. Check the other site's view. Confirm the receiving site now sees the item and the sending site still sees the history of its own departure.
8. Test the alert. Unplug one portal reader and confirm the supervisor is notified once the offline threshold passes (10 minutes by default).