Kupakia

Product Data Processes

Actualog manages product information as a connected set of Product Information Management processes.

A product is not simply entered into a form and stored. Its information is classified, structured, enriched, checked, reviewed, published, maintained, and reused throughout its lifecycle.

The main process is:

Model the product domain
→ Add and classify products
→ Enrich and normalize product data
→ Validate data quality
→ Review and approve
→ Publish and reuse
→ Keep products current

The same canonical product record moves through these processes. Actualog does not create a separate copy of the product for every team, catalog, or workflow.


Why Actualog uses processes

Technical product information changes over time.

Categories evolve. New attributes become important. Measurement units and validation rules change. Manufacturers release new models. Documents expire. Products are approved, published, corrected, discontinued, or replaced.

Actualog manages these changes as controlled processes so that users can understand:

  • what started an operation;
  • which products are affected;
  • who is responsible;
  • what has been completed;
  • what requires review;
  • why an operation was blocked;
  • what information was changed;
  • what can be retried safely.

This gives users the speed of collaborative data management while preserving validation, permissions, history, and accountability.


The product data lifecycle

1. Model the product domain

Before products can be described consistently, Actualog defines the structure of their information.

Category Experts and authorized administrators manage:

  • product categories;
  • universal and reusable category rules;
  • library attributes;
  • measurement units;
  • allowed values and controlled terminology;
  • required attributes;
  • product naming rules;
  • product identity rules;
  • effective category templates.

The effective template tells Actualog which information applies to products in a particular category.


2. Add and classify products

Products can enter Actualog through:

  • manual product creation;
  • supplier or manufacturer data import;
  • copying or extending an existing product;
  • AI-assisted creation and classification;
  • integration with another system.

Every product must be assigned to the appropriate category and product level.

Actualog then applies the category’s effective template so users can provide the correct attributes, units, media, documents, and relationships.


3. Enrich and normalize product information

Raw product data is rarely complete or consistent.

During enrichment, users and AI-assisted services can:

  • complete missing attributes;
  • normalize measurement units;
  • select controlled values;
  • improve names and descriptions;
  • add translations;
  • attach images and technical documents;
  • connect brands and manufacturers;
  • define product families, models, and variants;
  • add evidence and provenance.

The goal is to create one structured and reusable product record instead of maintaining multiple incompatible spreadsheets.


4. Validate product data

Actualog checks product information against the rules of its effective category template.

A product may be:

Data status Meaning
Ready No blocking data-quality issues were found.
Incomplete Required information is missing.
Invalid Existing information violates a rule.
Conflict Identity, duplicate, or structural conflicts require resolution.

Data status describes the quality of the product information. It is separate from approval and publication.

Users can filter products by issue, open the affected fields, correct the data, and run validation again.


5. Review and approve

Product governance controls whether canonical product data has been reviewed.

A product may move through:

Draft
→ Pending approval
→ Approved

A reviewer may also reject a product and provide a reason for correction.

Approval confirms that the product data has passed the required human review. It does not automatically make the product public.


6. Publish product information

Publication controls whether approved product information is internally managed or publicly available.

Publication is separate from workflow:

Publication status Meaning
Internal The product is managed in Actualog but is not publicly published.
Published The product is available through the permitted public or catalog experience.

Actualog checks workflow, data quality, identity, and other publication requirements before publishing a product.


7. Maintain products when the data model changes

Category models continue to evolve after products have been created.

When a new effective template is activated, Actualog may need to update existing products by:

  • applying new validation rules;
  • identifying newly required attributes;
  • safely converting measurement units;
  • regenerating names;
  • recalculating product identity;
  • recalculating data quality;
  • updating the search index.

Large updates run asynchronously in the background.

Existing products remain interpretable through their own stored template versions until they are safely updated. Actualog does not silently reinterpret old values using a new unit or rule.

Products that cannot be updated safely are left unchanged and presented for review.


8. Steward shared product information

Not every canonical product has an active Brand Owner.

Product Stewardship provides a governed workspace for:

  • Standard products;
  • branded products without a valid Brand Owner.

Category Experts can work with products in their assigned category scope. Application Administrators can work across the global stewardship scope.

When a valid Brand Owner becomes available, the same canonical product can move under company governance without copying the product or losing its history.


9. Update many products safely

Actualog supports operations that affect many products, such as:

  • changing shared attribute values;
  • filling missing values;
  • correcting mappings;
  • recalculating data quality;
  • refreshing products after template changes;
  • applying governed mass updates.

Before a mass operation is executed, Actualog should show which products are eligible, blocked, stale, unauthorized, or affected by conflicts.

Large operations run in the background and provide per-product results. A partial failure is not presented as complete success.


10. Reuse and distribute product data

Once product information is structured and governed, it can be reused in:

  • public product pages;
  • sales catalogs;
  • procurement catalogs;
  • exhibition catalogs;
  • partner catalogs;
  • exports and integrations;
  • search and comparison experiences;
  • AI-assisted discovery.

This is the purpose of the Actualog principle:

Create once, use many.

The canonical product record remains the source of truth, while catalogs and integrations present the information for different audiences and business scenarios.


Independent product states

Several states may apply to the same product at the same time.

Process dimension Question answered Examples
Workflow Has the product been reviewed? Draft, Pending approval, Approved, Rejected
Publication Is the product currently published? Internal, Published
Data quality Is the information complete and valid? Ready, Incomplete, Invalid, Conflict
Background operation Is a long-running process still working on the product? Waiting, Running, Completed, Blocked, Failed

These dimensions are intentionally separate.

For example, an approved product may become incomplete after a category template introduces a new required attribute. The product remains approved, but its data-quality issue becomes visible for correction.


Processes may continue in the background

Some actions affect one product and complete immediately. Others may affect hundreds or thousands of products.

Actualog performs large operations asynchronously so users can continue working.

A background process should provide:

  • progress;
  • successful results;
  • products requiring review;
  • technical failures;
  • retry options;
  • an audit trail.

Closing the browser does not cancel a durable background operation.


A typical end-to-end example

A manufacturer imports a spreadsheet containing new gas sensors.

Actualog:

  1. maps supplier columns to Actualog attributes;
  2. classifies the products;
  3. normalizes values and measurement units;
  4. detects product families and variants;
  5. identifies missing or invalid information;
  6. allows users to enrich the records;
  7. submits completed products for approval;
  8. publishes approved and ready products;
  9. reuses them in public and partner catalogs;
  10. keeps them current when category rules change.

Instead of repeating this work in separate spreadsheets, each step improves the same governed product record.


Learn about individual processes

The child topics in this section explain each process in detail, including:

  • who can start it;
  • what information is required;
  • what happens automatically;
  • which statuses may appear;
  • what can block the process;
  • how to correct and retry affected records;
  • how the result is recorded and reused.