A Tracking Mode Is a One-Way Door
An asset is tracked either as one record with one identity, or as a quantity in buckets. The choice is free until the first unit moves, and permanent afterwards — and the bucket is a six-part key that most people meet for the first time when their pool has fragmented into rows they did not expect.
Our take
Pooled tracking is the right answer for four hundred chairs and the wrong answer for four hundred laptops, and the test is not the count — it is whether anybody will ever need to say which one. If a unit can be individually blamed, individually serviced, individually recalled or individually returned to a specific person, it wants its own record. If the only questions you will ever ask are how many and where, a pool is dramatically less work. Get it wrong and the correction is not an edit: once units have moved, the mode is locked, and the way back is a new asset and a decommissioned old one. Decide it deliberately at registration, because that is the only moment the decision is cheap.
Four hundred chairs do not need four hundred records. Twelve laptops do. The system will let you choose either for either, once.
What the two modes actually are
An individually tracked asset is one record with one identity: an asset code, a barcode, a serial number, one custodian at a time, one location at a time, one movement history. Everything the register does — check-out, transfer, verification, retirement — happens to that record.
A quantity-pooled asset is one record describing a kind of thing, plus a set of balance rows describing how many of them are in each state. The record says "stacking chair, four hundred". The balances say where those four hundred are sitting and what condition they are in. Movements move quantities between balance rows rather than moving a record from one place to another.
The bucket is a six-part key
This is the part worth understanding before you pool anything, because it explains a phenomenon that surprises people: a pool of four hundred can turn into eleven rows without anybody intending it. A balance row is identified by six things together.
| Part of the key | What varies it |
|---|---|
| Custodian | Issuing units to a named person creates their own row. |
| Department | The same chairs held by two departments are two rows. |
| Warehouse | Branch-level separation, and the coarsest split. |
| Location | The shelf, bay or room within the warehouse. |
| Status | Available, assigned, checked out, in transit, maintenance, lost, damaged. |
| Condition | Excellent, good, fair, poor — a condition noted on receipt splits the row it lands in. |
Any distinct combination of those six is a distinct row, matched exactly, with empty values matched as empty rather than as wildcards. Move fifty chairs to the Mombasa store in fair condition and you have created a row that did not exist before. That is not a fault: it is the whole mechanism, and it is what lets a pool answer "how many good chairs are available in Nairobi" without a single individual record.
Movements come out of a named row, not out of the pool
When units move, the source is a specific balance row chosen by whoever is recording the movement — not the pool in general. A row with nothing in it is refused as a source. This is deliberate: "move fifty chairs" is ambiguous when the four hundred are spread across six rows in three conditions, and resolving that ambiguity by guessing would quietly relocate the wrong stock.
Two refusals, and what they protect
The register enforces exactly two rules about pooled tracking, and both of them fire at the point of editing the asset.
-
The mode cannot change once balances exist
Switch from pooled to individual after units have moved and the register refuses, in those words. The reason is that the two modes store history in different places — a pooled asset's past is a set of quantity movements between rows, and an individual asset's past is a sequence of custody events on one record. Converting one into the other would either invent detail that was never captured or discard detail that was.
-
The pool quantity cannot drop below what is tracked
If four hundred chairs are accounted for across balance rows, the asset's declared pool quantity cannot be set to three hundred. The declared quantity is the ceiling; the balances are the reality; and a ceiling below the reality would make every subsequent report disagree with itself.
Omitting a field is not the same as changing it
Both rules are written so that a partial update — an edit that changes the name and says nothing about tracking — leaves the mode and the quantity exactly as they were. The fields are dropped from the payload when the caller does not mention them. This matters most on the interface, where a client sending a subset of fields is normal and a mode silently rewritten to its default would be catastrophic and invisible.
The declared quantity is a ceiling. The balance rows are the truth.
Choosing, in one question
Somebody will one day ask which one
Track individually
Serial numbers, warranties, service history, a specific person to chase, a specific unit to recall. If any of those apply, the identity is the point and a pool discards it.
The only questions are how many and where
Pool the quantity
Chairs, cones, jerry cans, scaffolding clips, uniforms. Four hundred records for these is four hundred things to maintain and no information gained.
Some of them are special
Split the register, not the mode
Twenty of the four hundred chairs are in the boardroom and get replaced on a different cycle. Two assets — a pooled one and an individually tracked set — is the honest shape, and it stays correct as they diverge.
You genuinely cannot tell yet
Start individual
It is the mode that keeps more information, and information you did not need is recoverable in a way that information you never captured is not. Consolidating later is a decision; reconstructing later is not possible.
What the dashboard tells you about a pool
Pools are summarised separately from individual assets, and the figures are worth reading precisely. The register reports how many assets are pooled, the total units across all balance rows holding anything, how many of those units are available, how many are outside — meaning assigned, checked out, in transit, or held by a named custodian — and how many sit in a lost or damaged state. Rows holding zero are excluded throughout, so a bucket that has been emptied stops inflating the count of places your stock is in.
What AWRA OpsHub does today
- Two tracking modes per asset — individually identified, or a quantity pool — chosen at registration and stored on the record.
- Balance rows keyed on custodian, department, warehouse, location, status and condition together, matched exactly, with a row created at zero when a movement needs a combination that does not yet exist.
- Row-level locking on every quantity movement, so two simultaneous issues from the same bucket cannot both succeed against the same units.
- An explicit source balance on every movement, with an empty row refused as a source, so a quantity movement always names where the units came from.
- A refusal to change tracking mode once balances exist, and a refusal to set a declared pool quantity below the quantity actually tracked.
- Partial updates that leave tracking mode and pool quantity untouched when the caller does not mention them, on the web and interface paths alike.
- Pool figures on the asset dashboard — pooled asset count, total units, available units, units outside and units in a lost or damaged state — computed over rows holding stock.
- The same approval policy applied to pooled movements as to individual ones, so a bulk issue is gated on the same terms as a check-out.
More we can add to your workspace
- A conversion path between the two modes, migrating a pooled asset into individually identified records or consolidating records into a pool, with the history restated rather than discarded.
- A merge of balance rows that differ only by condition, for the common case where a receipt noted a condition and fragmented a bucket nobody wanted split.
- A per-unit serial register underneath a pool, so a pooled asset can still answer which specific units went where when a subset needs identifying.
- A suggested mode at registration based on the quantity and category being entered, offered as a prompt at the one moment the choice is free.
- A view of a pool's full movement history as a single ledger, reading across every balance row rather than a row at a time.
- A minimum quantity and a reorder prompt on a pool, so a pool that has been issued down to nothing announces itself the way stock does.
Where we point you to a specialist
- We will keep refusing a mode change on an asset that has moved units. The two modes record fundamentally different histories, and a conversion that silently invented per-unit detail from quantity movements would produce a register that looks more precise than the evidence behind it. Where a conversion is genuinely needed, it belongs in a migration with somebody accountable for the restated history, not behind a dropdown.
- Deciding which of your asset classes deserve individual identity is an operational judgement about how you work, and it stays yours. We will happily talk it through with your register in front of us; publishing a rule that says everything above a certain value is tracked individually would be arbitrary in most organisations.
- Where a regulator, funder or insurer requires per-unit identification of a class of asset, that requirement governs and the pool is the wrong tool regardless of how many units there are. We will point you at that conversation rather than offering a pooled record that satisfies the letter of a count and none of the intent.
Row consolidation and a suggested mode at registration are the two contained pieces here — both work with the data that already exists, and both remove a decision people currently have to get right from memory.
Making a pool easier to live with
The mechanism is sound and the friction is in the edges — fragmented rows, a mode chosen before anybody understood the consequence, and a history that reads a bucket at a time.
Row consolidation
Merge balance rows that differ only in a field you do not track by, with the movement history preserved against the merged row.
A pool ledger
One chronological history for the whole pool, reading across every bucket, so a stock discrepancy can be traced without opening rows individually.
A prompt at registration
A suggestion, at the only moment the choice is free, based on the quantity and the category being entered.
We publish scope, not dates.
Scope pooled trackingFive questions to ask before you pool anything
Can I change my mind about the tracking mode?
A good answer sounds like
A clear yes or no, with the condition.
What ours actually is
Until the first unit moves, yes. After that the register refuses, in those words, on the edit.
What identifies a balance row?
A good answer sounds like
A named key, not "the location".
What ours actually is
Six fields together — custodian, department, warehouse, location, status and condition — matched exactly.
What happens if two people issue from the same bucket at once?
A good answer sounds like
A lock, or a refusal.
What ours actually is
The source row is locked for the duration of the movement, so the second issue waits and then sees the updated quantity.
Can I reduce the declared quantity?
A good answer sounds like
Not below what is tracked.
What ours actually is
Exactly that, and the refusal names the tracked total so you can see what you are up against.
Do pooled movements need approval like individual ones?
A good answer sounds like
Yes, on the same policy.
What ours actually is
Yes. The same mode, action list and high-risk policy govern both.
Decide it once, deliberately
If you are about to register a few hundred of something, the ten minutes spent deciding how it should be tracked are the cheapest ten minutes in the whole exercise. We are happy to be the second opinion.
Talk through tracking modesFrequently asked questions
Why is the tracking mode locked once units have moved?
Because the two modes record different kinds of history and neither can be derived from the other. A pooled asset's past is a series of quantity movements between buckets; an individual asset's past is a sequence of custody events on one identity. Converting a pool into records would have to invent which specific unit went where, and converting records into a pool would have to throw that away. The refusal is the honest response to both.
My pool has split into more rows than I expected. What happened?
A balance row is keyed on six things together, and condition is one of them. Receiving units and noting their condition creates a row for that combination, as does issuing to a named custodian or moving to a different shelf. Nothing has gone wrong — the rows are an accurate description of where your units are. Consolidating rows that differ only by a field you do not care about is the piece of work most often asked for here.
Can I see the whole history of a pooled asset in one place?
Movements are recorded against the balance rows they moved between, so today the history reads a bucket at a time. A single chronological ledger across every bucket is on the list above; it is a reporting change rather than a structural one, since the movements themselves already carry both ends.
What counts as a unit being "outside" on the dashboard?
A unit in a row whose status is assigned, checked out or in transit, or in any row that has a custodian on it. That second condition matters: units issued to a named person are outside your control even when their status still reads available, and counting only on status would understate it.
If some of my pooled items need serial numbers, what do I do?
Split them into a separate individually tracked asset rather than trying to make the pool carry identity. Two assets describing two populations stays correct as those populations diverge, which they usually do — the identified subset ends up on a different replacement cycle, a different service schedule, or a different insurance line.
Does a pooled asset get a barcode?
The asset record does, on the same terms as any other — generated automatically unless you supply one, and unique within your workspace. What it identifies is the kind of thing rather than a specific unit, which is exactly the trade being made. A scan of that code tells you which pool you are looking at, and the balance rows tell you the rest.
