Skip to main content

Use-Case Playbooks

A playbook is an end-to-end plan for one kind of deployment. Each one starts from the outcome you want, then walks through how to model your data, where to put readers, which workflows and alerts to build, and what to check in the first week. They link to the detailed guides instead of repeating them, so read a playbook for the shape of the solution and follow its links for the field-by-field steps.

If you have never tracked anything in Tagnet, do Your First Tracked Item first. It takes one tag from nothing to an automatic move, and every playbook builds on that same path.

Choose a playbook​

If you track...Start withYou get
Jobs, assemblies, totes, or parts moving between stations on a production floorManufacturing WIP TrackingLive position of every unit, station dwell time, and a shipping hand-off to your ERP or MES
Laptops, servers, equipment, and other capital assets across buildings and roomsIT and Capital Asset TrackingA living asset register, alerts when tagged assets leave a building, and an auditable lifecycle from receipt to retirement
Consumables stocked in customer cabinets or bins that you replenishVendor-Managed Inventory for ConsumablesReceipts into the right cabinet, consumption events, and a feed to your replenishment system
Poles, transformers, and similar equipment moving between yards and out to a networkUtility Infrastructure TrackingDepartures and arrivals at yard gates, ownership that follows the stock between sites, and a network-wide view of what is in transit

Real deployments often combine two. A utility has a transformer repair shop that follows the WIP pattern; a manufacturer ships finished goods through a dock door that follows the utility yard pattern. Read the playbook closest to your biggest problem and borrow sections from the others.

What every playbook contains​

Each playbook uses the same five sections, so you can find the same answer in any of them:

  1. The outcome: what you have when the deployment works, and what it deliberately does not do.
  2. How to model it: item types and whether they track quantity, the location hierarchy, instance ID and tag ID schemes with sequence generators, and custom fields.
  3. Reader placement: which pattern from Reader Setup Recipes fits each place a tag passes, and what each reader's read point means.
  4. Workflows and alerts: the Move Inventory targets and transaction types, notifications, calls to other systems, and which alerts to route to people.
  5. What to check in the first week: the specific places in Tagnet that tell you whether the design is working.

How movement works in every playbook​

All four use the same movement model, so it is worth knowing once.

  • An item is where it was last read. A reader asserts presence. When a tagged item is read at a read point, a workflow decides what that means and moves the item. Tagnet does not infer that an item left a place because its tag stopped being read.
  • A read point is a location set on a reader or its device group. You set it on the device edit page or the group page. See Read Point Location and Device Groups.
  • A read point plays one of two roles, chosen by the workflow. At a place (a workstation, a bench, a cabinet) the location is where items land, and the Move Inventory target Read point's location moves them there. At a threshold (a site portal, a doorway) the location is what the reader guards, and the Within read point tag condition separates items leaving from items arriving.
  • Move Inventory is the only movement mechanism you build. It has five targets: the read point's location, a location by code in the device's scope, a specific location, a sibling location by type, and remove from inventory (for ships and consumes). Items already at the target are left alone, and a tag one Move Inventory action handled is skipped by later ones in the same run.
  • The transaction type states what kind of movement it was. Pick it for its business meaning (Receive, Transfer, Ship, Consume). Later actions, such as a call to your ERP, can route on it with the Transaction type code condition. Close-out types (Ship, Consume, Decommission) take the item out of live inventory. See Inventory Item Lifecycle.

Before you build any playbook​

Work through Setting Up Tagnet so a site, the catalog basics, and one reporting reader exist, and read the short section there on why the steps come in order. Then build the playbook's model first (locations, item types, identifiers, custom fields), then readers, then workflows. Workflows come last because they refer to everything else.