Skip to main content
Properties let you enrich entities with custom pieces of information. Where Tags organize assets under a controlled vocabulary, Properties document them: a last-validated date, an internal model ID, an owning organization, a loan portfolio reference. Properties are defined centrally, so the same field means the same thing everywhere it appears. They live in the same Govern area as the Tag Browser, and defining or changing them requires the CloudAdmin or Librarian role. Everyone else fills in values on their own assets.

How it works

Each property definition carries:
  • A name, which identifies the property on every asset it applies to.
  • A type, which constrains the values users can enter.
  • An optional description explaining what the property captures.
  • An optional group, which keeps related properties together.
  • A list of applicable assets: Apps, Projects, Project Templates, Datasets, NetApp Volumes, and Models.
Once defined, a property is available for assignment on every asset type listed for it. Properties have no hierarchy and no namespaces, and outside the select types below, no predefined set of values: any value that matches the property’s type is accepted.

Property types

Set property values

Set and update values from the asset’s overview page. The asset’s owner can do this, as can SysAdmins and CloudAdmins. On Apps and Models, global and per-version values coexist. That lets you record stable, asset-wide information alongside values that change as you iterate.

Carry property values into new Projects

When a Project Template is created, its creator picks one of three behaviors for each property, which decides what a Project created from the template starts with: Property values on the template’s Datasets, NetApp Volumes, and Apps carry over to the corresponding assets in the new Project.
  • Tags: categorize the same assets with a controlled, hierarchical vocabulary.
  • Knowledge management: how Tags, Properties, and search relate, and when to choose each.