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.
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.
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:
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
| SKU | KIN-RS-2704 |
| Category | ASG > Cargo > Kinedyne |
| Operating Company | kinedyne |
| Family | Cargo Securement |
| Exports to | kinedyne.com, Kinedyne distributors |
| Visible to | Kinedyne enrichers, Cargo team, ASG admin |
| SKU | WIS-LS-5040 |
| Category | ASG > Cargo > Wistra |
| Operating Company | wistra |
| Family | Cargo Securement |
| Exports to | wistra.de, European distributors (de_DE) |
| Visible to | Wistra 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 | 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
bigcommerceSalesforce
CRM product catalog, CPQ, and sales team product sheets
salesforceDistributor Feed
Structured data exports for third-party distributors and trade networks
distributor_feedHigh-resolution assets and long-form specs for catalogs, sell sheets, and brochures
printDAM
Digital Asset Management sync for images, videos, CAD files, and specification PDFs
damD365 Sync
Dynamics 365 Finance & Operations master data synchronization for ERP
d365_syncSupported 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 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 |
|---|---|---|---|---|
code | Text (identifier) | ohmite | kinedyne | Unique key, used in rules and API filters |
company_name | Text (localizable) | Ohmite Manufacturing | Kinedyne LLC | Display label in product grid and exports |
business_group | Simple Select | ASG | ASG | Groups companies for admin-level scoping |
d365_legal_entity | Text | OHM | KIN | Maps to D365 DataAreaId for integration sync |
headquarters | Text | Rolling Meadows, IL | Greensboro, NC | Location context |
country | Simple Select | United States | United States | Regional filtering, GDPR scoping |
website_url | Text (URL) | ohmite.com | kinedyne.com | Links in exports and print catalogs |
logo | Image | ohmite-logo.svg | kinedyne-logo.svg | Channel exports, print headers |
active | Boolean | true | true | Deactivate 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.
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.
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)
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.
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.
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.
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
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
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
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
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.
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.
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.
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.
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).
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.
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.
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
Catalog Manager
Manage families, attributes, categories; configure completeness
Enrichment Lead
Edit products within assigned categories; approve enrichment
Contributor
Edit assigned attribute groups for products in their operating company
Viewer
Read-only access to product data within assigned categories
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
# 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.
# 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
| Feature | Admin | Catalog Mgr | Enrichment Lead | Contributor |
|---|---|---|---|---|
| Configure AI models & prompts | ✓ | — | — | — |
| Trigger bulk AI enrichment | ✓ | ✓ | — | — |
| Request AI suggestion per product | ✓ | ✓ | ✓ | ✓ |
| Approve AI-generated content | ✓ | ✓ | ✓ | — |
| View AI audit log | ✓ | ✓ | — | — |
Heico Enrichment Pipeline
D365 Import
Product master data syncs from Dynamics 365 F&O: SKU, name, UOM, base pricing, item group
Rule Execution
Auto-set operating company, copy D365 name, apply family defaults, assign initial category
AI Description Generation
Franklin AI generates SEO short/long descriptions from technical specs and product name
AI Translation
Descriptions auto-translated to fr_CA, de_DE, nl_NL, pt_BR with industry terminology
Enrichment Lead Review
Human review of AI-generated content, approval or revision before publishing
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).
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
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
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.
# 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 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
DAM master
Content Fragments
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.