Copyable example for devices, servers and SaaS records. Illustrative rows contain fictional identifiers; do not place secrets or unnecessary personal data in an inventory.
Stuart Kerr Spindlow has confirmed personal use and testing of the software covered by Happy SysAdm. The assessments here distinguish documented behaviour from measured results; worked scenarios are labelled and are not personal test records.Choose a stable record key
A spreadsheet with stable identifiers can be adequate for a small, slowly changing estate with one accountable maintainer. A discovery-backed inventory becomes preferable as turnover, multiple data sources and reconciliation work grow. Automated discovery improves observation; it does not decide service ownership or retirement. Keep those human decisions explicit whichever tool holds the record.
Give each asset an internal ID that remains stable through renaming or reassignment. Record serial numbers, cloud resource identifiers or tenant references in separate fields. A hostname is useful for operations but may change or be reused.
Decide the unit of inventory. A physical host, its virtual machines and a SaaS subscription have different lifecycle properties. Link related records rather than squeezing all of them into a single ambiguous device row.
Capture fields that lead to action
Include asset type, service, accountable owner, location or region, lifecycle state, support end date and management source. Add last-seen and last-verified dates so stale discovery data is visible. For sensitive systems, record the classification without putting actual sensitive data in the inventory.
The example table is intentionally small enough to copy. Extend it with backup policy, patch group and supplier references when those fields have clear owners. A large catalogue of unmaintained optional fields can obscure the few facts that matter.
| Asset ID | Type / service | Owner role | State / verification |
|---|---|---|---|
| EX-001 | VM / internal file service | Infrastructure lead | In service / 23 September 2026 (fictional record) |
| EX-002 | Laptop / staff endpoint | Endpoint team | Assigned / 23 September 2026 (fictional record) |
| EX-003 | SaaS / documentation | Service owner | Active subscription / 23 September 2026 (fictional record) |
Reconcile rather than blindly import
Compare directory, endpoint-management, cloud and procurement records. Investigate duplicates, devices that have stopped checking in and billed resources with no owner. Automated discovery establishes that something was observed; it does not prove who is responsible for it or whether it should still exist.
Keep an exception list with an owner and due date. Do not automatically delete a record because a laptop was offline during a scan. Confirm retirement through the lifecycle process and retain evidence required by the organisation.
Use lifecycle gates
At onboarding, assign ownership and management before the asset enters service. During operation, update the record when role, location or support status changes. Before disposal, confirm data handling, access removal and contract consequences.
At handover, verify that another authorised person can locate the asset and its recovery or support record. Review access to the inventory itself; hostnames, software versions and network details can be sensitive operational information.
Calculate reconciliation coverage without double-counting
Suppose a worked example contains 100 directory records and 95 endpoint-console records, with 90 assets matched between them using reliable identifiers. The observed union is 100 + 95 − 90 = 105 distinct assets. There are ten directory-only and five console-only records to reconcile, not merely a five-device difference.
This calculation assumes the matches are correct and both lists refer to the same inventory unit and reporting period. It measures disagreement between sources, not the number of physical devices that certainly exist. Investigation may identify retired records, unmanaged assets or duplicate identities.