Skip to main content

Product Information Management

A product model as precise as the parts you sell.

Define the entities, attributes, groups and rules that describe motors, fasteners, valves and every other product type you carry, without forcing them into one generic template.

Walk through it All capabilities

How it works

Shape a motor family and see what each change affects

Browse attribute groups, inspect an attribute, make it required and watch the schema-change preview count affected products. Add your own attribute or adjust dimensions to recalculate package volume.

MODEL

  1. Industrial productBase entity: identity, logistics
  2. Family: AC induction motorAdds electrical and mechanical groups
  3. 312 productsValidated against this schema

Attributes marked inherited come from the base entity and are shared with every family.

ATTRIBUTE

Phase

Type
enum
Defined on
AC induction motor
Populated
274 of 312

Optional: missing values do not affect completeness.

CALCULATED

Package volume = length x width x height

1362.49 in³ recalculated from source values

The capability

The structure everything else depends on

Product data modeling defines what a product record is. In Autonera, a base entity carries identity and logistics data shared by everything you sell. Product families extend that base with the technical attributes that matter for each category, so an AC motor has rated voltage and frame size while a hex bolt has thread pitch and grade.

Each attribute has a type, an optional unit or measurement family, allowed values and a group that decides where it appears for editors and reviewers. Calculated attributes derive values such as package volume or formatted short descriptions from maintained fields, so dependent data never drifts from its inputs.

Models change as your assortment changes. Before a new requirement is enforced, Autonera shows how many existing products would become incomplete and lists them for remediation, so schema changes are planned rather than discovered by failed exports.

Functional capabilities

What Product Data Modeling includes

Configurable entities and families
Model base product entities and family-specific extensions without code changes.
Typed attributes
Text, number, enumerated list, measurement with unit, boolean, date and reference types with validation built in.
Attribute groups
Organize attributes into editing and review groups such as electrical, mechanical and logistics.
Inheritance
Define attributes once at the base or family level and inherit them into every product that uses that structure.
Calculated attributes
Derive values from expressions over maintained attributes, recalculated whenever inputs change.
Schema change impact
Preview how many records a new requirement or type change affects before it is enforced.
Model versioning
Track model changes over time and review them through the same approval workflow as data changes.

Problems it solves

Where this work usually breaks down

  1. 01

    One spreadsheet layout for every product type

    Generic columns force technical values into free-text fields, which cannot be filtered, compared or validated.

  2. 02

    The same attribute defined three ways

    Voltage stored as text in one family and as a number in another breaks comparison, faceted search and syndication.

  3. 03

    Derived values maintained by hand

    Package volume, weight classes and formatted titles diverge from their source values after the first update.

  4. 04

    Schema changes that surprise everyone

    Adding a required field without impact analysis blocks hundreds of records from publishing overnight.

In industrial operations

A motor and drive distributor standardizes 40 product families

A distributor carrying motors, drives and power transmission parts inherited supplier-specific spreadsheets with inconsistent columns for the same specifications.

  1. Product data teams define a base entity with identity, brand and logistics attributes.
  2. Each family gets typed technical attributes, units and allowed values grouped for engineering review.
  3. Package volume and shipping class become calculated attributes instead of manual columns.
  4. Before requiring phase on all motors, the impact preview lists the records that need values, and the team fills them before enforcement.

Result: Every family shares one consistent foundation, technical values become searchable and comparable, and schema changes are released without blocking publication.

Related capabilities

Works alongside

Feature guide

Product Families & Variants

Family templates, variant axes and inherited values with SKU-level exceptions.

Feature guide

Product Hierarchies & Taxonomy

Classification trees with inherited category requirements and controlled reassignment.

Feature guide

Industrial Classification & Standards Mapping

Crosswalk local classes and features to ETIM, ECLASS and UNSPSC.

Feature guide

Packaging & Trade-Item Hierarchies

Each, inner, case and pallet levels with quantities, weights and identifiers.

Capability area

Product Information Management

See where Product Data Modeling fits in the wider Product Information Management capability.

Autonomous operations

How autonomous execution changes product data modeling

Agents use the model as their contract: they know which attributes each family requires, what type and unit each value must have and which values are derived.

Agents carry out

  • Suggest attribute definitions from supplier columns
  • Detect values that violate type or unit
  • Backfill newly required attributes from approved sources
  • Recalculate derived values after bulk changes

People decide

  • Approve new attributes and family structures
  • Decide when a requirement is enforced
  • Own allowed values and naming conventions

Evidence recorded

  • Model change history with approvers
  • Records affected by each schema change
  • Source of every backfilled value

Buyer FAQs

Questions evaluators ask

Can different product types have completely different attributes?

Yes. Families extend a shared base entity with their own attributes, groups and requirements, so each product type carries only the fields that apply to it.

Do model changes require developers?

No. Entities, attributes, groups, inheritance and calculated attributes are configured by authorized administrators and can be routed through approval.

How are units handled?

Measurement attributes are tied to a measurement family, so values are stored with a valid unit and can be converted for downstream channels.

What happens to existing records when we add a required attribute?

Autonera previews how many records would become incomplete and lists them, so you can fill values before the requirement is enforced.

Can calculated attributes be overridden?

Calculated attributes are derived from their inputs. If a manual value is needed, model it as a separate attribute so the derivation remains trustworthy.

Your next step

See Product Data Modeling on data like yours.

Bring a real file, catalog or record set. We will walk through how Autonera would handle it and where your team keeps the final say.

Book a Demo