Templates: Concepts
A template is a class and a model entity is an instance — Infohub's templating is genuine object orientation over the model.
Most tools that call something a template mean "a copy-paste starting point". Infohub means something stronger. An Infohub template is a class, a model entity created from it is an instance, and the relationship between them persists — so improving the class improves every object.
Understanding it in those terms makes the whole feature predictable.
Class and instance#
Infohub's model tree holds both kinds of entity, distinguished internally by their type:
| Template (the class) | Model entity (the instance) |
|---|---|
| Template folder | Folder |
| Template metric | Metric |
| Template measure | Measure |
| Template event scheme | Event scheme |
Templates live in the Template view; instances live in the Model view. They are the same kinds of thing, in two different spaces.
An instance keeps a link back to the template it came from. That link is what makes an instance an instance rather than a copy, and it is what allows an update to the template to reach it later.
A model entity with no such link is a purely local entity — an ordinary object, belonging to nobody.
What you get from it#
Build once, deploy many. Twelve mixers with the same eight measures, three limits, and two charts: one template, twelve instantiations.
Improve once, everywhere. A better utilisation formula, an extra measure, a corrected unit — change the template, update the instances.
Consistency by construction. Instances cannot drift apart accidentally, because they came from one definition. Reports that compare equipment work because the equipment is genuinely modelled the same way.
Much smaller models to maintain. A hundred templated instances are one thing to look after, not a hundred.
Templates plus attributes#
A template alone describes shape. It becomes genuinely reusable when combined with model attributes, which supply what differs per instance.
The template refers to attributes in tag addresses, queries, calculations, and entity names:
[ModelAttribute("Unit Number")]-FT-001.PV
Each destination folder carries its own attribute values, so one template resolves to a different tag, a different capacity, and a different name per instance.
This is the pairing to internalise: template = shape, attributes = specifics. A template with hard-coded tags is not reusable; a template with no attributes usually should have some.
Release before instantiate#
A template must be released before it can be instantiated. Releasing publishes the template definition as available for use.
An unreleased template instantiates nothing, quietly. Attempting to instantiate a template that has not been released does not produce a helpful error — it produces no entities. If instantiation appears to succeed but nothing arrives in the destination folder, check that the template is released first. This is the single most common templating surprise.
The sequence is always: author the template, release it, then instantiate.
Versions and drift#
A template carries a version, and each instance records the template version it was created or last updated from.
Comparing the two tells Infohub whether an instance is current or has drifted behind. An instance already at the template's current version is skipped during an update — which keeps updates cheap and means running an update twice is harmless.
This is also how you can tell, in a large model, which instances have received a change and which have not.
Specialisation: local additions survive#
An instance is allowed to have content the template does not.
If you add a purely local measure to a templated metric — a one-off calculation that only this machine needs — that measure has no template link, and template updates leave it alone. It is a specialisation of the instance.
This is the safe way to handle the exception. When eleven mixers fit the template and the twelfth needs one extra measure, add that measure locally to the twelfth instance. Do not delink the whole instance, and do not add the measure to the template and then delete it from eleven instances. Local additions are a designed capability, not a workaround.
What you should not do is edit a templated member of an instance and expect the edit to survive. Templated members are owned by the template, and an update will overwrite them.
Locking properties to enforce standardisation#
Owning a member is not the same as fixing every field on it. By default an instance can still change a templated measure's individual properties — its scaling, its expression, its retrieval settings — and then lose those changes at the next update, having had no warning that they were the template's business.
Locking is how a template says which properties it owns outright. Each lockable property carries a padlock on the template, and locking it means:
- On every instance, that field becomes read-only. The padlock appears there too, so whoever is editing can see why the field will not accept input rather than assuming Infohub is broken.
- On a derived template, the lock is inherited and cannot be released. A child template may lock more, never less — so a standard set centrally cannot be quietly relaxed one layer down.
Two rules worth knowing before planning a hierarchy:
- Only an administrator can change a lock, and only on the template itself. Someone working on an instance cannot unlock a field, which is the entire point.
- An instance shows a padlock only where the property is genuinely locked. An unlocked field looks ordinary, so the absence of a padlock means the instance really does own that value.
Locks are recorded per property, so one template can fix the calculation expression while leaving the time scheme free, or fix the retrieval configuration while allowing a local scaling factor.
Lock what correctness depends on, not everything. A template with every property locked is a template nobody can adopt: the first site with a legitimately different tag name has to delink, and then you have lost the linkage altogether. Lock what makes the KPI comparable across sites — the expression, the aggregation type, the limit definition — and leave what is legitimately local, such as tag names and offsets, unlocked.
Some configuration refuses deletion rather than editing. Removing an event trigger or a refresh offset that the template locked reports that the configuration is locked at template — the same mechanism seen from the other side.
Delinking#
Delinking removes the link between an instance and its template, demoting the instance to ordinary local content. It keeps everything — the folders, metrics, measures, values, and charts stay exactly as they are — but the relationship is gone, and future template updates will not reach it.
Delinking cascades downward: delinking a metric delinks the measures beneath it.
Use it when a piece of equipment has genuinely diverged from the pattern and will now be maintained on its own. Do not use it to escape an update you did not want, because the link cannot be casually recreated and you lose all future improvements.
Optional members#
Template members can be marked optional, which affects whether an update creates them on instances that do not have them.
The behaviour to plan around: instantiation creates every member, optional or not. Optionality is honoured when updating, not when instantiating.
So a template with optional members produces complete instances, and the optional marking becomes relevant when you later add a member to the template and update existing instances. If you need instances that genuinely differ in which measures they contain, either delete the unwanted members from those instances after instantiation, or use separate templates.
Scripted instantiation does not consider optionality. When instantiating from the CLI, optional marking is not taken into account. Expect a complete set of members from a scripted instantiation, and handle any per-instance differences explicitly afterwards.
What is worth templating#
Template it when a structure appears three or more times, when consistency across instances is a requirement, or when the pattern is still evolving and you expect to improve it.
Do not template it for one-off equipment, for site-wide summary measures that exist once, or for a structure you do not yet understand well enough to have built one good example of.
That last point is the practical rule: build one instance completely by hand first. Get its chain, calculations, limits, and charts right, confirm the numbers, and only then turn it into a template. A template built from a half-understood pattern gets instantiated twenty times and then needs reworking twenty times.
Author in the Template view#
Create template content directly in the Template view, in a template folder, rather than building it in the Model view and converting it.
Measures inherit template-ness from their parent, so authoring a template metric and adding measures to it produces template measures without further ceremony.
One limitation to design around#
Attribute-driven naming — where an attribute value shapes the name of the created entity — is available for folders, metrics, and event schemes, but not for measures. Template measure names come through as authored.
Design around it by naming template measures for the quantity and interval (Steam Flow Hourly) and letting the containing metric and folder carry the instance identity (Line 03 Steam). This reads better anyway: the full path is Line 03 → Steam → Steam Flow Hourly, and repeating the line number on every measure would be noise.
Where to go next#
- Templates: Instantiating and Updating — the operations, in order, and what to check
- Model Attributes — the other half of reusable templates
- Template Servers and Federation — sharing templates between instances and sites