Asset properties, templates and property logs

What it does

Asset properties are configurable attributes on a customer asset — capacity, refrigerant type, firmware version, RAM — defined as data rather than as custom columns. Property templates bundle a set of properties so you can apply them to an asset category or a functional location type in one move. Property logs keep the history of a property's value over time.

Key facts

Property definitions live at Settings > Asset Properties > Property Definitions. Each has a Property Name and a Property Type.
Supported types are number, string, boolean and date/time. That's the whole list — no option sets, no lookups, no currency.
Templates are at Settings > Asset Properties > Templates for Properties. You add properties to a template through New Property Template Association, and you can create a property definition inline while doing it.
A template is linked to an asset category through the Asset Categories section on the template (New Asset Category Template Association), which pushes its properties onto assets in that category.
Templates can also be applied to an individual asset: open the asset > Related > Asset Template Associations > New Asset Template Association.
A single property can be attached straight to one asset without a template, via Related > Property Asset Associations on the asset.
Functional location types can carry property templates too, so a "plant room" type can bring its own attribute set to every location of that type.
Property logs record a value at a point in time. A log entry takes a customer asset, a functional location, a Reading Time (defaults to now, editable) and the value.
Logs are created from the property definition's Related > Property Logs — the documented flow is manual entry, not automatic capture from a work order.
Applying a template to a category affects assets in that category; assets already carrying properties keep what they have, so retro-fitting a template is not the same as re-templating existing data.

When to use / skip

Use properties when the attributes vary by kind of asset and the client can't or shouldn't get a schema change every time they add an equipment type. A servicing business with forty categories of kit, each with its own nameplate data, is the textbook case — properties keep that in configuration rather than in the solution.

Skip properties for attributes that every asset has and that the business actually filters, sorts, reports or drives logic on. Serial number, install date, warranty end, model — those want to be real columns on the asset table. Properties are stored as associations, which makes them awkward in views, advanced find, Power BI and workflow compared to a plain field. The rule of thumb: shared and queried means a column, varied and descriptive means a property.

Property logs specifically are worth it only where the value genuinely changes and the trend matters — meter readings, hours run, filter replacement counts. If nobody will ever look at the second reading, don't build the process.

Configuration decisions

Which attributes are properties and which are columns on the asset table. Decide this once, write it down, and hold the line — mixed models are where reporting projects die.
Whether templates are driven from asset categories, functional location types, or both. Category-driven is the common answer; location-driven only earns its place in facilities scenarios.
The category taxonomy itself, since templates hang off it. Categories that are too coarse mean half-empty property sets; too fine means dozens of near-identical templates.
How property values get captured in the field. Inspections are the usual answer for readings, with properties holding the static nameplate data, but that's a design you have to make deliberately.
Whether property logs are in scope at all, and if so who creates them and how often — manual logging is a real process cost.
Naming and units. Because the type system is only four primitives, "Capacity" needs to be "Capacity (kW)" or someone will type litres into it.

Gotchas

The four data types are a hard constraint. There is no picklist property, so any controlled vocabulary ends up as free-typed strings and drifts within a month. Plan validation or accept the mess.
Properties do not surface like columns. Building a view of "all assets where refrigerant = R410A" is not the two-minute job the client expects after the demo.
Template application isn't retroactive in the way people assume. Adding a property to a template later does not neatly rewrite every asset that used it, so sequence template design before bulk asset creation.
Property logs require both a customer asset and a functional location. Clients who chose not to use functional locations find this out at the worst moment.
Inspections and properties are separate systems that look similar. Inspection responses do not automatically become property values, and consultants get caught promising otherwise.
Bulk-loading property values is fiddlier than loading assets, because you're writing association records rather than columns. Budget for it in the migration, not after.

Consultant notes

Ask the client for one real equipment nameplate photo per category at the design workshop. It settles the properties-versus-columns argument faster than any discussion.
Demo the category-to-template link, not just a single asset with properties — the point of the feature is applying a set to a group.
Push back when someone asks for a property that every asset will have. That's a field. Adding it as a property to "avoid customisation" costs more later than the column ever would.
If readings matter, design the inspection-to-property story explicitly and tell the client what's manual. The documented log flow is hand-entered, and pretending otherwise creates a gap at UAT.
Before go-live, check a technician's security role can actually read property definitions and associations, or the asset form will look strangely empty on mobile.

Worth another look if property capture from inspections becomes native, or if additional property data types ship.