Akeneo PIM
Configuration & Architecture Guide

Category Hierarchy & Catalog Structure

How Heico's product catalog is organized: from master catalog root through business group divisions down to individual product lines and SKUs.

Category Design Principles for Heico

The category tree is designed with three critical requirements in mind: permission scoping, operating company isolation, and acquisition scalability.

Interactive Category Tree

How Categories, Operating Company & Products Connect

The relationship between the three concepts is the foundation of Heico's PIM governance. Here's how they work together:

Estimated Product Counts by Operating Company

Product volumes vary dramatically across Heico's subsidiaries. The PIM architecture must handle companies with 50 SKUs alongside companies with 5,000+.

The Three-Way Relationship

Categories, Operating Company, and Families serve different purposes but are tightly linked. Here's how they differ:

Akeneo Attribute Types

All 17 attribute types available in Akeneo PIM, with descriptions and Heico-specific examples for each.

Attribute Properties

Product Families

10 product families representing Heico's diverse industrial product lines. Each family defines which attributes are available and required for its products.

Validation Rules Engine

Akeneo's rule engine automates data enrichment, validation, and transformation. Here are 6 production-ready rules configured for Heico's PIM instance.

Validation Types

Completeness Model

Completeness measures how much required data is filled for a product per channel and locale. Products only export to a channel once they hit the configured threshold.

Required Attributes: Cargo Securement Family

Completeness Dashboard (Mock)

Output Channels & Locales

6 channels define where product data is distributed. 6 locales support Heico's North American, European, and South American markets.

Supported Locales

Reference Entities

Reference entities provide centralized, reusable lookup data linked to products. They eliminate duplication and ensure consistency across the entire catalog.

Operating Company: The Governance Backbone

The operating_company attribute is the single most important governance mechanism in Heico's Akeneo instance. It controls visibility, scopes exports, powers dashboards, and enforces multi-tenant isolation across 70+ subsidiaries — all within a single PIM instance.

How It Works

Reference Entity Record Structure

Each Operating Company is stored as a record in the reference entity. These are the fields on each record — not to be confused with the product-level operating_company attribute, which is a single-link that points to one of these records.

Scoped Product Grid Views

Akeneo's product grid can be filtered by operating_company, creating dedicated views per subsidiary. Each user role sees a different default scope.

Two-Layer Governance: Categories + Operating Company

Akeneo's native permission system controls visibility through category access, not reference entity values. The operating_company attribute then layers on top as the filter for exports, dashboards, and API queries. Together, they form Heico's complete multi-tenant governance.

User Group → Category Access Mapping

Each user group is granted permission on one or more category nodes. Since the category tree mirrors the company structure, this effectively scopes users to their operating companies.

How the Two Layers Interact: Example

Scoped Exports & Channel Distribution

Every export profile, connector, and API query can be filtered by operating_company. This means each subsidiary gets its own data feed without maintaining separate PIM instances.

channel: bigcommerce
filter:
  operating_company:
    operator: IN
    value: ["kinedyne"]
  completeness:
    operator: "="
    value: 100
    scope: bigcommerce
  enabled: true
# Only 100% complete, enabled Kinedyne products export

channel: distributor_feed
format: csv
filter:
  operating_company:
    operator: IN
    value: ["ohmite", "arcol"]
  completeness:
    operator: ">="
    value: 80
    scope: distributor_feed
# Ohmite + Arcol (both Electronic Passives) in one feed

channel: print
filter:
  operating_company:
    operator: IN
    value: ["pettibone"]
  locale: en_US
include:
  - company_logo # from ref entity
  - company_name # catalog header
# Pettibone-branded catalog with logo from ref entity

GET /api/rest/v1/products
  ?search={
    "operating_company": [{
      "operator": "IN",
      "value": ["kinedyne"]
    }],
    "updated": [{
      "operator": "SINCE LAST N DAYS",
      "value": 1
    }]
  }
# Delta sync: only Kinedyne products changed in last 24h

Dashboards Scoped by Operating Company

Every dashboard metric — completeness, enrichment progress, channel readiness — can be viewed at the company, group, or global level.

Acquisition Onboarding via Operating Company

When Heico acquires a new company, operating_company is the mechanism that brings them into the PIM without disrupting existing data. Here is the repeatable playbook:

Operating Company Across the Entire System

The operating_company attribute touches every layer of the architecture:

Permission Hierarchy & Governance

Five-level permission model controlling who can view, edit, enrich, and publish product data across Heico's operating companies.

Access Matrix

Akeneo REST API

Akeneo exposes a comprehensive REST API for integration with external systems. OAuth2 authentication, JSON payloads, cursor-based pagination.

Filtering & Pagination

# Filter products by family and completeness
GET /api/rest/v1/products?
  search={"family":[{"operator":"IN","value":["cargo_securement","fasteners"]}]}
  &search={"completeness":[{"operator":">","value":80,"scope":"bigcommerce"}]}
  &limit=100

# Cursor-based pagination (recommended for large datasets)
GET /api/rest/v1/products?
  pagination_type=search_after
  &search_after=abc123def456
  &limit=100

# Filter by updated since (for delta syncs)
GET /api/rest/v1/products?
  search={"updated":[{"operator":"SINCE LAST N DAYS","value":7}]}

AI-Powered Enrichment

Akeneo Franklin AI and custom rules-based automation accelerate product data enrichment, reduce manual effort, and maintain consistency across 70+ operating companies.

Franklin AI Capabilities

Rules + AI Pipeline

The enrichment pipeline combines deterministic rules with AI-assisted generation. Rules fire first (fast, predictable), then AI fills gaps.

# Phase 1: Deterministic Rules (run on product save)
rules:
  - set_operating_company:    # auto-assign based on category
      priority: 100
      trigger: on_create
  - copy_d365_product_name:   # sync from ERP master
      priority: 90
      trigger: on_import
  - set_default_compliance:   # apply per-family defaults
      priority: 80
      trigger: on_create

# Phase 2: AI Enrichment (run on enrichment request)
ai_enrichment:
  - generate_description:
      model: franklin_v3
      inputs: [product_name, technical_specs, family]
      outputs: [short_description, long_description]
  - auto_categorize:
      model: franklin_classifier
      confidence_threshold: 0.85

# Phase 3: Human Review
review:
  queue: enrichment_review
  assign_to: enrichment_lead

AI Permission Model

Heico Enrichment Pipeline

Data Architect Agent Concept

Integration Connectors

Three tiers of connectors link Akeneo to Heico's ecosystem: native (built-in), partner (certified), and ecosystem (community/custom).

Adobe Experience Manager (AEM) Integration

There is no native first-party Akeneo ↔ AEM connector, but the integration is well-documented via API patterns. If Heico uses AEM for web content management or digital asset management, here are four integration paths:

# 1. Asset published in AEM Assets
event: asset:published
path: /content/dam/heico/kinedyne/KIN-RS-2704-hero.jpg

# 2. Middleware extracts metadata
operating_company: kinedyne  # from folder path
sku: KIN-RS-2704          # from filename convention
asset_type: hero           # from filename suffix

# 3. Push to Akeneo Asset Manager API
POST /api/rest/v1/asset-families/product_images/assets
Body: { "code": "KIN-RS-2704-hero",
        "values": { "media": [binary] } }

# 4. Akeneo product link rule auto-assigns
rule: asset code starts with product SKU
result: KIN-RS-2704.hero_image = KIN-RS-2704-hero

# Akeneo product payload (simplified)
{
  "identifier": "OHM-TF-5025",
  "family": "resistive_components",
  "values": {
    "product_name": "50W Thick Film Resistor",
    "resistance": { "amount": 25, "unit": "OHM" },
    "marketing_description": "High-reliability..."
  }
}

# Transformed to AEM Content Fragment
POST /api/assets/{path-to-fragment}
Model: resistive-component
Properties: {
  "sku": "OHM-TF-5025",
  "productName": "50W Thick Film Resistor",
  "resistance": "25 Ω",
  "description": "High-reliability..."
}

PIM Architect Key Concepts & Interview Reference

Essential Akeneo PIM architecture concepts every PIM Architect must know — data modeling, integration patterns, and platform internals.

Catalog Data Model Design — Walkthrough

"Walk me through how you would design the data model for a catalog with variants."

Building Plugins & Extensions for Akeneo PIM

Three development paths for extending Akeneo: Custom Components (in-PIM UI), Iframe Extensions (embedded external apps), and Custom Apps (API-connected external services).

Choosing Your Extension Method

Akeneo provides three distinct paths for extending the PIM. The right choice depends on where your logic runs, how tightly it integrates with the UI, and whether you need real-time event subscriptions.

Extension Method Decision Matrix