Logs and registers

Most of what your organisation tracks takes one of two shapes. A log is a running account of what happens at your places, growing every shift. A register is a list of the things you look after, each with a short history of its own — and knowing which one you are building tells you how to shape the tree and its forms.

The running log

A log answers one question: what happened, where, and when? Its tree maps your places — the organisation at the top, its sites, the areas within each site and the locations within those. Once it is set up, that tree changes little. What grows is the entries: every check, delivery, visitor sign-in and incident is filed at the place it happened, so a busy location gathers hundreds of entries over a few months.

A few choices keep a log easy to read as it grows:

• Keep the tree to places. The levels say where something happened, not what happened. The kind of event belongs on the form, as a question near the top, rather than as extra levels in the tree. Splitting events into branches would scatter one location's history across several items.
• Ask when it happened. Every entry notes when it was created, but people often log an event after the fact. A date and time question on the form lets someone capture a late-shift incident the next morning without skewing the timeline.
• Let one form branch. A single log form can cover many kinds of event by showing follow-up questions only once they apply — a fault description for a repair, a docket number for a delivery. See conditional questions.
• Add a lifecycle only where follow-up matters. Most log entries describe something that happened once and need no status. For the ones that do — a repair request that has to be closed off — attach a lifecycle, or have one attached automatically to the kinds of entry that need it.

A log is read by time and by place. Entries roll up the tree, so a site's page brings together everything filed at its areas and locations, and someone given access to a site can see that site's whole history. To narrow a long log to one week or one kind of event, use the table's filters and sorting.

Shift logs, routine checks and walkthroughs, incident and hazard reports, visitor sign-ins and deliveries all suit a log.

The register

A register answers a different question: what do we have, and what condition is each one in? Here the tree lists things rather than places. The lowest level is the things themselves — each vehicle, each piece of equipment, each set of safety gear — grouped under a type above them. You add an item when you take something on and remove it when it leaves, so the tree itself is your inventory.

Entries in a register are about the item they are filed against: an inspection, a service, a safety test. Each item gathers only a handful over its life, and its page reads as that item's own history.

A register works best when:

• Every thing is its own item. Each thing needs a place of its own — its own page, its own history, its own access. Filing every inspection against a single item for all your vehicles would leave you unable to tell one van's history from another's.
• Items carry the names your team uses. Name each one by its asset code, registration plate or serial number, so the directory's search finds it by the identifier people already quote.
• Two levels are often enough. A type, such as vehicles or cleaning equipment, then the items beneath it. Name each level with a category, so Pyron speaks about an asset rather than a generic item.
• Facts about the thing stay on the thing. Details that describe the item itself — its make, model or purchase date — belong with the item, not repeated on every inspection. An item can carry its own details through a form of its own, chosen when you add it. The entry form then asks only what changes from one inspection to the next.

Because access follows the branch, you can share one type with the team responsible for it — the vehicles with your fleet staff, say — without opening the rest of the register. See access and sharing.

Vehicles and fleet, plant and equipment, IT hardware, keys and access cards, and scaffolding all suit a register.

Mixing both in one workspace

You do not have to pick one shape for everything. The directory holds several trees side by side, each starting from its own root with its own categories, so a log of your sites and a register of your equipment sit together in the same directory.

Give each shape its own tree. A category belongs to a single tree, so a log's levels (site, area, location) and a register's (type, asset) never tangle. When you create a root, Pyron asks which kinds of entry that tree will keep: one your organisation already has, a fresh kind you name on the spot, or none for the moment, so you can lay out the places first. You can add more kinds later.

A kind of entry you add to an item applies to that item and everything beneath it. That lets a register keep inspections across every type while vehicle services appear only under the vehicles branch. The same kind cannot be added twice along one branch, so there is never any doubt about where an entry of that kind belongs.

One tree can also keep several kinds of entry at once — announcements, maintenance requests and site summaries under a single root, for example. Each kind then has its own page and its own table, so you move between them rather than filtering one mixed list.

When a log entry concerns something in a register — a fault on a van spotted during a site walk — file it where it will be followed up. A note about the place belongs in the log; anything that changes the item's condition belongs against the item, so its history stays complete.

To shape the levels of each tree, see designing your tree.