Spreadsheets are useful inventories, but persistent object records solve different lifecycle and field-access problems.
This guide is written for practical use: it focuses on information that should remain understandable after installation, handover, maintenance or staff changes. The objective is not to collect the maximum possible data, but to keep the right data structured, traceable and easy to use at the physical object.
Spreadsheets are good at overview
A table is efficient for filtering many assets, importing data and reviewing current fields in bulk. It remains a useful export and administration format.
Object records are good at depth
An individual identity can carry photos, documents, public/private views and a lifecycle history without forcing all of that information into columns.
Use stable IDs between both
A persistent identifier lets bulk data and individual object pages refer to the same asset. CSV import or export can then complement rather than replace the object record.
Choose both when appropriate
A mature asset system often needs a register view for management and a detailed identity view for work at the physical asset.
Practical focus
Use the spreadsheet or register view for breadth and the persistent object record for depth. A stable ID joins the two: bulk data remains easy to manage while documents, public identity and history stay attached to the individual asset.
Start with reliable master data
A register is only useful when each row represents one real asset consistently. Establish stable IDs, clear names, locations and serial or manufacturer information before adding complex workflows.
- Use a stable unique asset ID.
- Prefer structured status and location fields over free-text notes.
- Define who is responsible for correcting duplicate or incomplete records.
Combine register-level overview with object-level detail
The table view is ideal for filtering and bulk work; an individual object record is better for documents, photos, public identity and lifecycle history. Both views should reference the same stable asset.
- Keep CSV import/export as an interoperability tool.
- Do not force photos and maintenance history into spreadsheet cells.
- Link physical labels back to the same persistent record.
Plan for changes in ownership and location
Assets move, get reassigned and eventually retire. Record these changes without destroying prior context so handover, audits and maintenance remain understandable.
How to choose between the options
Use the simplest approach that still preserves stable identity, traceability and the level of access your workflow needs. Avoid choosing technology only because it is newer; consider cost, environment, expected lifetime and who will actually use the record.
- Prefer durable identifiers over temporary labels.
- Separate physical carrier choice from the underlying digital identity.
- Plan how the record will be maintained after the initial rollout.
A practical decision rule
If the information changes often, keep it in the digital record. If it must remain visible without a device or network connection, keep a concise human-readable version on the physical label as well.
A practical implementation workflow
Treat the first version as an operational baseline rather than a one-off document. Start with a small representative sample, check that another person can understand the identifiers and fields without verbal explanation, then apply the same structure consistently. The workflow should be simple enough to repeat during installation, handover and later maintenance, because a technically perfect record that nobody keeps updated quickly loses value.
- Pilot the structure on a few real objects before rolling it out in bulk.
- Define which fields are mandatory and which are optional before importing or printing labels.
- Test links, QR codes and exported files on the actual devices and materials used in the field.
- Record who owns the data quality and who is expected to update the record after a change.
Review the record as part of the lifecycle
Good documentation is not finished when the first record is created. Review it whenever the physical object changes, when responsibility is handed over, or when an inspection or maintenance event reveals new information. A short periodic review is usually more reliable than trying to reconstruct several years of undocumented changes later. The aim is to keep the current view accurate while preserving enough history to understand important decisions.
- Update the current state after material changes instead of adding contradictory notes.
- Keep dated evidence for changes that may matter during troubleshooting, audit or handover.
- Retire obsolete information deliberately rather than leaving several competing versions in circulation.
Common mistakes to avoid
Avoid duplicate asset IDs, inconsistent status values, one giant notes field and separate spreadsheets that cannot be reconciled. A large register with unreliable identity is less useful than a smaller accurate one.
A sensible next step
Start with a small asset register, clean the IDs and core fields, then link individual assets to persistent identities only where documents, QR access or history add value.