◈ PIM Deep Dive

Akeneo PIM
Configuration & Architecture Guide

The Heico Companies — Comprehensive reference for PIM configuration, data modeling, validation rules, API patterns, and AI-powered enrichment across all business groups.

Prepared by Jason Lotzer
Date March 2026
Scope 4 Business Groups · 70+ Operating Companies
17
Attribute Types
10
Product Families
6
Channels
6
Locales

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.

Catalog Structure Flow
Master Catalog
Business Group
Product Division
Product Line
SKU

Category Design Principles for Heico

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

🏢

Company = Category Node

Every operating company has its own category node in the tree. Products are placed under their company's node, which triggers the auto-assignment rule that sets the operating_company attribute. This creates a 1:1 link between category placement and operating company ownership.

📂

Division Groups Companies

Companies are grouped under product divisions (Cargo Solutions, Electronic Passives, etc.). Granting a user group access to a division node gives them visibility across all companies in that division — enabling cross-company teams without per-company permission setup.

Acquisitions = New Nodes

When Heico acquires a company, it gets a new category node under the appropriate division. Existing families, attributes, channels, and locales are all reused. The new node plus a reference entity record is all that's needed to onboard.

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:

Category Node
ASG > Cargo > Kinedyne
Auto-Assignment Rule
operating_company = “kinedyne”
Product Scoping
Views, Exports, Dashboards

A product placed in the Kinedyne category node automatically gets operating_company: kinedyne via a priority-100 rule. From that point forward, the attribute drives all downstream scoping — which exports include it, which dashboard it appears on, and which API queries return it.

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+.

Operating Company Business Group Division Product Family Est. Products Catalog Complexity
Kinedyne ASG Cargo Solutions Cargo Securement 3,842 ●●● High — many SKU variants per strap/chain
Ancra International ASG Cargo Solutions Cargo Securement 2,100 ●●● High — global, multi-locale
Wistra ASG Cargo Solutions Cargo Securement 950 ●● Medium — de_DE locale required
Ohmite ASG Electronic Passives Resistive Components 1,247 ●●● High — deep technical specs per resistor
Arcol ASG Electronic Passives Resistive Components 380 ●● Medium — similar schema to Ohmite
Pettibone ASG Heavy Equipment Heavy Equipment 250 ●● Medium — few SKUs, rich specs each
Barko ASG Heavy Equipment Heavy Equipment 180 ●● Medium — forestry equipment + attachments
Shred-Tech ASG Recycling Solutions Industrial Shredders 120 Low — configurable machines, few base SKUs
Wakefield-Vette ITG Thermal Solutions Thermal Management 1,800 ●●● High — heat sinks with many form factors
Spartan Tool ITG Water Infrastructure Drain/Sewer Equipment 892 ●● Medium — machines + replacement parts
Electric Eel ITG Water Infrastructure Drain/Sewer Equipment 200 Low — Nov 2025 acquisition, onboarding
Davis Wire MPG Steel Wire Products Steel Wire 2,000 ●●● High — gauge/coating/spool combinations
Infasco MPG Fasteners Fasteners 4,500 ●●● Very high — grade/size/finish matrix
TITAN Formwork CSG Construction Equipment Formwork/Shoring 350 ●● Medium — rental + purchase variants
Total Estimated Catalog (Phase 1–2 companies shown) ~18,800 Full rollout: 25,000–40,000+

The Three-Way Relationship

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

Category Operating Company Family
What it is A node in the navigation tree A reference entity record linked to each product An attribute template applied to a product
Primary purpose Permission scoping + browsing Export scoping + governance identity Defines which attributes exist on a product
Controls Who can see the product in the PIM UI Where the product goes (exports, feeds, APIs) What data fields the product has
Relationship A product can be in multiple categories A product has exactly one operating company A product has exactly one family
Shared across companies? No — company-specific nodes in the tree No — one record per company Yes — Kinedyne and Ancra share “Cargo Securement”
When new company is acquired New category node created New reference entity record created Existing family reused (usually)

Concrete Example: Two Products, Same Family, Different Companies

📦 Kinedyne Ratchet Strap
SKUKIN-RS-2704
CategoryASG > Cargo > Kinedyne
Operating Companykinedyne
FamilyCargo Securement
Exports tokinedyne.com, Kinedyne distributors
Visible toKinedyne enrichers, Cargo team, ASG admin
📦 Wistra Lashing Strap
SKUWIS-LS-5040
CategoryASG > Cargo > Wistra
Operating Companywistra
FamilyCargo Securement
Exports towistra.de, European distributors (de_DE)
Visible toWistra enrichers, Cargo team, ASG admin

Same family (Cargo Securement) — same attributes, same completeness rules. Different categories — different user visibility. Different operating companies — different export destinations. This is how one PIM instance serves 70+ companies without data leakage.

🔐
Why This Matters for Heico

A Kinedyne enricher cannot accidentally edit a Wistra product even though both use the Cargo Securement family with identical attributes. The category tree enforces visibility. The operating_company attribute enforces export isolation. The shared family ensures consistent data modeling. Three mechanisms, one clean governance model — and no per-company PIM instances to maintain.

Akeneo Attribute Types

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

Attribute Properties

Property Description Impact
Localizable Values can differ per locale (e.g., en_US vs fr_CA) Product descriptions, marketing copy, labels
Scopable Values can differ per channel (e.g., bigcommerce vs print) Short vs long descriptions, different images per channel
Unique Value must be unique across all products SKU identifiers, UPC codes, part numbers
Required Must be filled for completeness calculation Controls which products are ready for export
Validation Regex, min/max, URL format, email format constraints Ensures data quality at the point of entry

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

Type Applies To Example
Regex Text, Text Area, Identifier ^[A-Z]{2,4}-\d{4,8}$ for SKU format
Min/Max Length Text, Text Area Short description: 50–160 characters
Min/Max Value Number, Metric Weight: 0.01 – 99999 kg
Allowed Extensions Image, File jpg, png, webp for product images
URL Format Text Product specification sheet links
Date Range Date Certification expiry cannot be in the past

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

Attribute BigCommerce Salesforce Distributor Print DAM D365
SKU
Product Name
Short Description
Long Description
Hero Image
Price (USD)
Weight
Working Load Limit
Certifications
Material

Completeness Dashboard (Mock)

💡
Completeness = Data Readiness

Completeness is not about filling every field—it is about ensuring every required field for a specific channel/locale combination is populated. A product at 100% completeness for BigCommerce may still be at 60% for Print if the print channel requires additional specification data like detailed dimensions and compliance marks.

Output Channels & Locales

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

🛒
BigCommerce

B2B & B2C e-commerce storefronts for direct sales to contractors and end users

bigcommerce
Salesforce

CRM product catalog, CPQ, and sales team product sheets

salesforce
📦
Distributor Feed

Structured data exports for third-party distributors and trade networks

distributor_feed
🖨
Print

High-resolution assets and long-form specs for catalogs, sell sheets, and brochures

print
🎨
DAM

Digital Asset Management sync for images, videos, CAD files, and specification PDFs

dam
D365 Sync

Dynamics 365 Finance & Operations master data synchronization for ERP

d365_sync

Supported Locales

🇺🇸
English (US)
en_US
🇨🇦
English (CA)
en_CA
🇨🇦
French (CA)
fr_CA
🇩🇪
German
de_DE
🇳🇱
Dutch
nl_NL
🇧🇷
Portuguese (BR)
pt_BR

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 Single Link

Every product has exactly one operating_company attribute — a single-link to the Operating Companies reference entity. This creates a hard, unambiguous relationship: one product belongs to one company.

Auto-Assigned by Rules

A priority-100 rule fires on product creation. Based on the category the product is placed in, the rule automatically sets operating_company — enrichers never need to set it manually.

🔒

Locked After Assignment

Only PIM Administrators and the D365 integration service account can modify operating_company after initial assignment. Contributors and enrichers see it as read-only.

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.

Record Field Type Example (Ohmite) Example (Kinedyne) Purpose
codeText (identifier)ohmitekinedyneUnique key, used in rules and API filters
company_nameText (localizable)Ohmite ManufacturingKinedyne LLCDisplay label in product grid and exports
business_groupSimple SelectASGASGGroups companies for admin-level scoping
d365_legal_entityTextOHMKINMaps to D365 DataAreaId for integration sync
headquartersTextRolling Meadows, ILGreensboro, NCLocation context
countrySimple SelectUnited StatesUnited StatesRegional filtering, GDPR scoping
website_urlText (URL)ohmite.comkinedyne.comLinks in exports and print catalogs
logoImageohmite-logo.svgkinedyne-logo.svgChannel exports, print headers
activeBooleantruetrueDeactivate without deleting (post-M&A cleanup)

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.

⚡ Ohmite 📦 Kinedyne 🔧 Spartan Tool 🌐 All Companies (Admin)
🏢 Ohmite Manufacturing ASG · Electronic Passives
1,247 products
SKU Product Name Family Completeness Status
OHM-TF-502550W Thick Film Resistor, 25ΩResistive Components 96%Enabled
OHM-WW-100KWirewound Resistor, 100KΩ 10WResistive Components 100%Enabled
OHM-HS-2512SMD Heatsink Resistor, 1W 2512Resistive Components 72%Draft
OHM-PW-250Planar Resistor, 250W Chassis MountResistive Components 45%Incomplete
💡
Key Insight: Contributor Isolation

When a Kinedyne enricher logs in, they only see Kinedyne products. They cannot browse, search, or export Ohmite, Spartan, or any other company's data. This isolation is the result of two complementary layers working together — category-based permissions and the operating_company attribute. See below.

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.

Layer 1 Category Permissions

Controls: Which products a user can see and edit in the PIM UI

Mechanism: User groups are granted own, edit, or view access to specific category tree nodes

Inheritance: Granting access to a parent category automatically includes all children

Enforced by: Akeneo's native permission engine (server-side, cannot be bypassed)

Layer 2 Operating Company Attribute

Controls: Which products appear in exports, feeds, dashboards, and API queries

Mechanism: Export profiles and API calls filter by operating_company value

Flexibility: Can group multiple companies in one export (e.g., Ohmite + Arcol combined feed)

Enforced by: Export profile filters, API query parameters, dashboard aggregation

Layer 1 answers: “Who can see and touch this product?”  •  Layer 2 answers: “Where does this product go?”

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.

User Group Category Access (Own/Edit) Products Visible Use Case
Ohmite Enrichers ASG > Electronic Passives > Ohmite Ohmite only (~1,247) Single-company enrichment team
Electronic Passives Team ASG > Electronic Passives (parent node) Ohmite + Arcol (~1,600) Multi-company team managing related brands
Cargo Solutions Team ASG > Cargo Solutions (parent node) Kinedyne + Ancra + B/A + Wistra + LoadLok (~8,500) Cross-brand cargo team
ASG Group Admin ASG (top-level group node) All ASG companies (~15,000) Business group oversight
Water Infrastructure Team ITG > Water Infrastructure Spartan + Electric Eel + Rioned + KaRo (~2,100) Cross-company division team
Corporate Marketing All categories (view only, edit on Marketing attrs) All 70+ companies (~12,400+) Brand consistency, SEO, marketing copy
PIM Administrators All categories (own) Everything Crystal’s team: schema, rules, governance

How the Two Layers Interact: Example

Scenario: A distributor needs a combined product feed for Ohmite and Arcol electronic components.

Layer 1

The Electronic Passives Team user group has edit access on the ASG > Electronic Passives parent category. Both Ohmite and Arcol enrichers belong to this group, so they can see and edit products from both companies in the PIM UI.

Layer 2

The distributor export profile filters by operating_company IN ["ohmite", "arcol"]. This produces a single combined CSV with products from both brands, each clearly tagged with its operating company. Meanwhile, a separate BigCommerce export for ohmite.com filters by operating_company IN ["ohmite"] only.

Result

Same user group, same category access, but different export scopes. Category permissions control who can work with the data. The operating_company attribute controls where the data flows.

Why Two Layers Instead of One?

Category permissions alone can’t scope exports flexibly — you can’t easily say “export Ohmite + Arcol but not Stenograph” at the category level since they’re all under ASG. The operating_company attribute gives fine-grained, queryable control over data distribution independently from UI access. Conversely, operating_company alone can’t restrict what users see in the UI — that requires Akeneo’s category-based permission engine. Together, they cover the full governance surface.

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.

🛒 BigCommerce Store Feeds

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

Each operating company with a BigCommerce storefront gets its own export profile. Products from other companies are never included — even if they share the same product family.

📦 Distributor Data Feeds

Export Profile: Ohmite → Distributor CSV
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

Related companies can be grouped in a single export — Ohmite and Arcol share the Resistive Components family, so distributors may want a combined catalog. The filter supports arrays.

📄 Print Catalog Generation

Export Profile: Pettibone → Print PDF
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

Print exports pull the company logo and name from the Operating Companies reference entity, automatically branding each catalog for its subsidiary.

</> API Integration Queries

D365 Sync: Fetch by Operating Company
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

The D365 integration uses operating_company to scope delta syncs per legal entity. Each D365 company only receives its own product updates.

Dashboards Scoped by Operating Company

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

Completeness Dashboard
BigCommerce channel · en_US locale
By Company By Group Global
Kinedyne LLC94%
3,614 / 3,842 products completeASG · Cargo Solutions
Ohmite Manufacturing91%
1,135 / 1,247 products completeASG · Electronic Passives
Spartan Tool LLC83%
740 / 892 products completeITG · Water Infrastructure
Davis Wire Corporation76%
1,520 / 2,000 products completeMPG · Steel Wire Products
Pettibone LLC58%
145 / 250 products completeASG · Heavy Equipment · Recently onboarded
Electric Eel Manufacturing34%
68 / 200 products completeITG · Water Infrastructure · Nov 2025 acquisition
📊
Executive Visibility via Axiamatic

These per-company completeness metrics feed into Heico's Axiamatic program governance dashboard, giving CIO Thomas Gerdes real-time visibility into PIM onboarding progress per acquisition. When Electric Eel (acquired November 2025) shows 34% completeness, the executive team knows exactly where the enrichment bottleneck is.

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:

Step 1: Create Reference Entity Record

PIM Admin creates a new record in the Operating Companies reference entity with the company code, name, business group, D365 legal entity code, logo, and website URL.

5 minutesPIM Admin only

Step 2: Add Category Nodes

Add the new company's product categories under the appropriate business group in the category tree. Products imported into these categories will auto-inherit the operating company via rules.

30 minutesCatalog Manager

Step 3: Create Auto-Assignment Rule

Add a new rule that sets operating_company for any product placed in the new category nodes. Existing families are reused — no new families needed if the product types already exist.

15 minutesPIM Admin

Step 4: Create User Group & Permissions

Create a new user group scoped to the new operating company. Enrichers added to this group will only see products belonging to their company. Assign attribute group edit permissions (Technical, Marketing).

20 minutesPIM Admin

Step 5: D365 Product Import

D365 integration pushes the new company's products. The DataAreaId from D365 maps to the operating_company reference entity code. Products are created in the correct family, auto-categorized, and auto-assigned.

AutomatedD365 Integration

Step 6: Enrichment & Channel Activation

Company enrichers log in and see only their products. They add marketing descriptions, images, and specifications. Completeness rises on the dashboard. Once channel thresholds are met, products automatically appear in export feeds.

OngoingCompany Enrichers
No Schema Redesign Required

When Heico acquires a company whose products fit an existing family (e.g., Electric Eel uses the Drain/Sewer Equipment family), the entire onboarding is configuration only — one reference entity record, category nodes, a rule, and user permissions. No new families, no new attributes, no code changes. This is the power of domain-based families + the Operating Company governance model.

Operating Company Across the Entire System

The operating_company attribute touches every layer of the architecture:

System Layer How Operating Company Is Used Example
D365 Inbound Sync DataAreaId maps to operating_company code on product create/update DataAreaId “KIN” → operating_company “kinedyne”
Rules Engine Priority-100 rule auto-assigns based on category placement Product in “electronic_passives_ohmite” → operating_company “ohmite”
Product Grid (UI) Grid filtered by user group → operating company mapping Kinedyne enricher sees 3,842 products; Ohmite enricher sees 1,247
Completeness Dashboard aggregated per operating company per channel Kinedyne: 94% on BigCommerce, 87% on Distributor
Export Profiles Each export filtered by operating_company + channel + completeness Kinedyne BigCommerce feed: only 100% complete, enabled products
BigCommerce Connector Scoped per operating company storefront kinedyne.com receives only Kinedyne products
Distributor Feeds Can group related companies (Ohmite + Arcol) or isolate Digi-Key gets combined electronic passives feed
Print Catalogs Logo and branding pulled from reference entity per company Pettibone catalog auto-branded with Pettibone logo
API Queries First-class filter parameter in REST API ?search={"operating_company":[{"operator":"IN","value":["spartan_tool"]}]}
AI Enrichment AI rules can be scoped per operating company for tone/style Ohmite: technical/engineering tone; Kinedyne: safety/compliance tone
Axiamatic Governance Per-company metrics roll up to program dashboard for CIO visibility Electric Eel at 34% triggers onboarding milestone alert

Permission Hierarchy & Governance

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

👑
PIM Administrator

Full system access: schema, rules, API keys, user management

Level 5
🛠
Catalog Manager

Manage families, attributes, categories; configure completeness

Level 4
Enrichment Lead

Edit products within assigned categories; approve enrichment

Level 3
📝
Contributor

Edit assigned attribute groups for products in their operating company

Level 2
👁
Viewer

Read-only access to product data within assigned categories

Level 1

Access Matrix

Action Admin Catalog Mgr Enrichment Lead Contributor Viewer
Manage users & API keys
Create/modify families & attributes
Configure rules & completeness
Edit all product data
Edit assigned attribute groups
View product data
Export product data
Manage categories
Approve translations

Akeneo REST API

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

Filtering & Pagination

Product Search with Filters
# 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}]}
📚
Pagination Best Practice

Always use search_after cursor-based pagination for product exports. Page-number pagination becomes unreliable beyond ~10,000 products and can skip or duplicate records when data changes during iteration.

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

🤖
Auto-Categorization

ML model classifies new products into the correct category tree position based on attributes and description text.

📄
Description Generation

Generates SEO-optimized short and long descriptions from technical specs, adapting tone per channel.

🌐
Translation

AI-assisted translation with PIM-specific terminology dictionaries for fr_CA, de_DE, nl_NL, pt_BR.

📸
Image Recognition

Extracts attributes from product images: color, material, category suggestions, background removal.

🔬
Data Quality Scoring

AI evaluates descriptions for clarity, keyword density, and completeness beyond rule-based checks.

🔗
Attribute Mapping

Suggests attribute mappings when onboarding new operating companies from legacy spreadsheets.

Rules + AI Pipeline

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

Enrichment Pipeline Configuration
# 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

FeatureAdminCatalog MgrEnrichment LeadContributor
Configure AI models & prompts
Trigger bulk AI enrichment
Request AI suggestion per product
Approve AI-generated content
View AI audit log

Heico Enrichment Pipeline

1
D365 Import

Product master data syncs from Dynamics 365 F&O: SKU, name, UOM, base pricing, item group

2
Rule Execution

Auto-set operating company, copy D365 name, apply family defaults, assign initial category

3
AI Description Generation

Franklin AI generates SEO short/long descriptions from technical specs and product name

4
AI Translation

Descriptions auto-translated to fr_CA, de_DE, nl_NL, pt_BR with industry terminology

5
Enrichment Lead Review

Human review of AI-generated content, approval or revision before publishing

6
Channel Export

Products meeting completeness thresholds are exported to BigCommerce, Salesforce, distributors

Data Architect Agent Concept

An AI-powered agent that continuously monitors catalog health, suggests schema improvements, and identifies enrichment opportunities.

Schema Suggestions

Detects when products frequently have empty optional attributes and recommends adding them as required or removing them from the family.

Duplicate Detection

Identifies potential duplicate products across operating companies using fuzzy matching on name, specs, and images.

Completeness Forecasting

Predicts when product families will reach target completeness thresholds based on current enrichment velocity.

Category Optimization

Recommends category tree restructuring based on product distribution and navigation analytics.

Integration Connectors

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

● Tier 1 — Native Connectors

Built-In, Akeneo-Maintained

🛒
BigCommerce

Native Akeneo connector for product sync, categories, images

Salesforce Commerce

Product catalog, pricing, and asset sync to Salesforce

🔥
Adobe Commerce

Magento/Adobe Commerce product integration

● Tier 2 — Partner Connectors

Certified Partner Solutions

Dynamics 365 F&O

Custom middleware integration for ERP master data sync

🛍
Shopify

Partner connector for Shopify storefront product feeds

📦
Amazon

Marketplace product listing and content syndication

Adobe Experience Manager

AEM Assets (DAM), Content Fragments, AEM Guides — API-based integration

● Tier 3 — Ecosystem Connectors

Community & Custom Integrations

🎨
DAM Systems

Bynder, Cloudinary, or custom DAM for asset management

📊
ERP Systems

Generic ERP connectors for inventory, pricing, master data

🖨
Print & InDesign

Automated catalog generation for print production

🌐
Translation (TMS)

Transifex, Phrase, or Lokalise for localization workflows

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:

🎨

AEM Assets → Akeneo (DAM Integration)

Digital asset management — AEM as the asset master

Direction: AEM Assets → Akeneo Asset Manager (AEM is master of assets)

How it works: Product images, spec sheets, and marketing assets are managed in AEM Assets (DAM). A middleware layer listens for asset publish events in AEM and pushes assets to Akeneo’s Asset Manager API. Once in Akeneo, product link rules automatically associate assets with the correct products based on naming conventions or metadata.

AEM → Akeneo Asset Sync Flow
# 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

Heico value: Marketing teams manage brand assets in AEM’s familiar interface. Product enrichers in Akeneo never need to upload images manually — they appear automatically, already linked to the right product and operating company.

📄

Akeneo → AEM Content Fragments

Structured product data for headless web experiences

Direction: Akeneo → AEM Content Fragments (Akeneo is master of product data)

How it works: Enriched product data from Akeneo is pushed to AEM as Content Fragments. AEM defines a Content Fragment Model matching the Akeneo family structure (e.g., a “Resistive Component” model with fields for resistance, wattage, tolerance). Middleware transforms Akeneo’s JSON product payload into AEM’s Content Fragment API format.

Akeneo Product → AEM Content Fragment
# 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..."
}

Heico value: Subsidiary websites built on AEM can render product detail pages, comparison tools, and spec sheets using structured Content Fragments — all fed from the single source of truth in Akeneo. Content editors in AEM add contextual copy while product data stays in sync.

🌐

Akeneo → AEM Sites (Page Rendering)

Product pages and catalog browsing on AEM-powered websites

Direction: Akeneo → AEM Sites (via Content Fragments or direct API)

How it works: AEM Sites components pull product data from Content Fragments (pre-synced from Akeneo) or query Akeneo’s REST API directly at build/render time. AEM’s Dynamic Media with OpenAPI capabilities can reference assets stored in a remote DAM, including Akeneo’s Asset Manager.

Architecture options:

  • Pre-rendered: Middleware syncs Akeneo data to AEM Content Fragments on a schedule. Pages render from local AEM data. Best for SEO and performance.
  • Headless: AEM Edge Delivery or SPA frontend queries Akeneo API directly for real-time product data. Best for dynamic catalogs.
  • Hybrid: Core product data pre-synced as Content Fragments; inventory/pricing queried in real-time from D365. Best of both worlds.

Heico value: If Heico subsidiaries migrate from BigCommerce to AEM Sites for their web presence, the Akeneo product data layer remains unchanged — only the channel connector changes. The PIM architecture is channel-agnostic by design.

📚

Akeneo → AEM Guides

Technical documentation and product manuals

Direction: Akeneo → AEM Guides (Akeneo feeds product specs into documentation)

How it works: Adobe has published an open-source data source connector for Akeneo that fetches product data directly into AEM Guides. This enables technical writers to embed live product specifications into operator manuals, installation guides, and compliance documents.

Heico value: Companies like Pettibone (telehandlers), Barko (forestry equipment), and Spartan Tool (drain machines) maintain extensive operator manuals and technical documentation. Pulling specifications directly from Akeneo into AEM Guides ensures documentation always reflects the current product data — no manual copy-paste from spec sheets.

Akeneo ↔ AEM Integration Architecture

PIM
Akeneo
Products, Specs, Assets
Assets IN ←
→ Products OUT
Middleware
Azure / Node.js
Transform & Route
AEM Assets
DAM master
AEM Sites
Content Fragments
AEM Guides
Tech manuals

Assets flow IN from AEM to Akeneo (AEM is DAM master). Product data flows OUT from Akeneo to AEM (Akeneo is PIM master). The middleware layer handles transformation, authentication, and event routing for both directions.

No Native Connector — Custom Middleware Required

Unlike BigCommerce or Adobe Commerce, there is no drop-in Akeneo-AEM connector. The integration requires custom middleware using Akeneo’s REST API and AEM’s Assets/Content Fragment APIs. The same Azure Integration Services middleware proposed for the D365 integration (see heico-d365.jscriptz.com) can be extended to handle AEM sync as an additional outbound channel — scoped by operating_company per subsidiary website.

D365 F&O Integration Gap: Akeneo does not have a native Dynamics 365 Finance & Operations connector. This requires custom middleware (e.g., Azure Logic Apps, custom Node.js service, or iPaaS like MuleSoft) to sync product master data between D365 and Akeneo. This is the single largest integration effort in the Heico PIM deployment. See the companion D365-Akeneo Integration Architecture SPA for the detailed technical design.