Data Profiles

A data profile is the contract between a catalogue and your reference data. It decides which typed fields every listing in that catalogue carries — and, through the listing, which fields every asset placed from it inherits.

If you have ever wondered “why does this listing ask for airflow capacity but that one asks for lamp wattage?” — the answer is the data profile each catalogue is bound to.

The problem data profiles solve

Field definitions are the vocabulary of your data: power rating (kW), refrigerant type, installation date. Without a profile, every catalogue would have to copy those definitions into itself, and every copy would drift.

A data profile bundles field definitions into one published, numbered version. Catalogues bind to that version. Nothing is copied — the catalogue points at the profile, the profile points at the field library.

Without data profiles	With data profiles
Each catalogue invents its own fields	One published profile, reused by many catalogues
Editing a field silently changes old listings	Old listings keep the version they were created against
”Is this field required?” varies by catalogue	Requiredness is declared once, in the profile
No record of which schema an asset was captured under	Every listing and asset pins an exact profile version

How reference data fits together

Reference data lives under Administration → Reference data and comes in four independent kinds, each its own workspace:

FIELD LIBRARY ──defines──> field definitions (typed, versioned)
                                  │
DATA PROFILE ─────pins────────────┘  + requiredness, order, help text
      │
CATALOGUE ──binds to──> one published profile version
      │
LISTING ──carries──> the profile's fields, filled in
      │
ASSET ──inherits──> the listing's values, plus its own

Field library

Reusable typed fields — the words. Power rating, serial number, fuel type. Each field is published as an immutable version.

Data profile

The sentence. Picks published field versions and says which are required, in what order, and how they are shown.

Classification

Where an item sits in your equipment taxonomy. Independent of the profile — a listing chooses its classification separately.

Standards

Which standard editions an item complies with. Also chosen separately per listing.

Note

Data profiles replace the older per-catalogue “taxonomy” with custom fields. If you used an earlier version of the product, think of a profile as a taxonomy’s field list — lifted out of the catalogue so it can be shared and versioned.

Versions, and why they matter

A profile has two states at any time:

• A draft — mutable. You add fields, reorder, change requiredness.
• Published versions — immutable. Once published, a version never changes.

Catalogues bind to a published version, never to the draft. That is the whole point: when you improve a profile next month, nothing that was created against version 1 changes. Existing listings and assets stay valid under the version they were captured with, and you decide when — or whether — to move them forward.

Tip

Publish early. A catalogue cannot accept listings until it is bound to a published profile version, and a draft with two well-chosen fields is more useful than a perfect draft nobody can use yet.

Authoring a data profile

You need access to Administration → Reference data (typically a catalogue or reference-data administrator).

1. Open the Data profiles tab under Reference data. Each row is a profile workspace; each profile can have many published versions.

2. Create a profile with New profile. Give it a namespace and code (for example acme / hvac-plant), a display name, and a description. The namespace and code are how other workspaces refer to it — choose them once.

3. Open a draft from the profile row. Give the draft a title such as “v1 — plant room baseline”.

4. Add fields to the draft. For each field you choose:

   Setting	What it does
   Field key	The short name this profile uses for the field, e.g. power_kw.
   Field library workspace and Published field version ID	Which published field definition this key points at. The profile pins the exact version.
   Requiredness	required, requiredWhenApplicable, recommended, optional, or prohibited.
   Applies to	What the field is captured on: catalogueListing, estateAsset, site, building, space, drawing, or attachment.
   Control	How it is shown — single or multi-line text, number, toggle, date, single/multi select, classification or standard picker, measurement, money, attachment.
   Compact, Placeholder, Order	Presentation: dense layout, hint text, and position in the form.

5. Publish the draft. It becomes an immutable version listed under Published profile versions. The draft closes; open a new one to keep evolving.

Caution

Only published field definition versions can be pinned. If the field you want is still a draft in its field library, publish it there first.

Binding a profile to a catalogue

Every catalogue needs a data-profile target before it can hold listings. You can set it from two places:

• Inside the catalogue — the Set the data-profile target control on the catalogue’s detail page. Pick the profile workspace, then the published version.
• From the listing form — if you open Create a listing on a catalogue that has no profile yet, the form says This catalogue has no data profile yet and offers Choose data profile. Binding there sets the catalogue’s target and fills the form in.

Once bound, the listing form shows a Listing Fields card populated from the profile — every field the profile declares, with the requiredness and control you configured.

Moving to a newer version

Publishing version 2 of a profile does not rewrite anything bound to version 1. Catalogues, listings and assets keep pointing at the version they were created with until someone chooses to move them.

When you edit a listing and select a newer profile version, the form shows a migration notice: Saving will create a profile-migration receipt and carry the reviewed field values into the selected version. Save, and the listing is re-pinned to the new version with a receipt recording the source version, target version, and which values were carried across.

This is deliberate. Migration is a decision you make per record, with an audit trail — never a side effect of publishing.

Troubleshooting

You see	It means	Do this
Select a published data profile when saving a listing	The catalogue has no profile target.	Use Choose data profile on the form, or set the target on the catalogue detail page.
This workspace has no published data profile versions in the picker	The profile only has a draft.	Publish the draft under Reference data → Data profiles.
No data profile workspaces are available	No profile has been created yet.	Create one under Reference data → Data profiles.
Field definition is not available locally yet on a listing field	The pinned field version hasn’t synced to this device.	Wait for sync, or check the field library it points at is reachable.

Quick reference

Question	Answer
What’s a data profile?	A published, versioned bundle of field definitions a catalogue binds to
Where do listing fields come from?	The catalogue’s bound profile version
Can I edit a published version?	No — open a new draft and publish a successor
Does publishing v2 change my v1 listings?	No — they keep v1 until you migrate them, with a receipt
Where do I manage profiles?	Administration → Reference data → Data profiles

Related guides

• Understanding Catalogues
• Reference data
• Inside a catalogue
• Create a listing