Best practices for importing Salsify data (CSV/JSON) to create Content Fragments in AEM | Community
Skip to main content
M
Meghana_N
Level 2
March 30, 2026
Question

Best practices for importing Salsify data (CSV/JSON) to create Content Fragments in AEM

  • March 30, 2026
  • 1 reply
  • 34 views

Hi Community,

I’m looking for suggestions and best practices around importing Salsify product data into AEM, specifically for creating or updating Content Fragments.

Current Architecture

  • Salsify product data is exported and stored in AEM DAM as .txt files.
  • AEM Workflow is triggered on these DAM assets
  • The workflow:
    • Reads the Salsify JSON
    • Creates Product Pages
    • Sets product properties on the pages based on the JSON
  • This approach is currently page‑centric, driven by workflow logic

New / Evolving Requirement

We are exploring a shift to:

  • Content Fragments as the primary product data source
  • Importing product data via:
    • CSV files where one or more columns contain Salsify JSON, or
    • Directly from JSON assets
  • Mapping Salsify attributes to Content Fragment Models
  • Supporting re‑imports / updates (idempotent behavior)

What I’m Looking For

I’d appreciate guidance on:

  • Recommended patterns for CSV/JSON → Content Fragment creation
  • Whether workflows are still the preferred approach, or if:
    • Custom servlets
    • Schedulers
    • Asset processing
    • Or other AEM-native mechanisms are better suited
  • How teams are handling:
    • Large Salsify JSON payloads
    • Partial updates vs full re‑imports
    • Storing raw source JSON for traceability
  • Any lessons learned from real-world Salsify + AEM integrations

We’re currently on AEM as a Cloud Service and dealing with product data at scale, so performance and maintainability are important.

Looking forward to hearing how others have approached this.
Thanks in advance!

1 reply

Harwinder-singh
Community Advisor
Harwinder-singhCommunity Advisor
Community Advisor
March 30, 2026

​@Meghana_N  How big is the product catalog? what is the average size of your sku data payload?

Based on that we can explore couple of design patterns. You can go with a pure dynamic API route, where you have AEM templates for different PDP layouts and a sling model can feed the sku data directly from PIM Apis. If you are looking for more content control , localization, performance gain, you might want to stick with CFM route. The only thing that you do to make your life easier is to split the CFM models based on the type of sku data, core product data , SEO attributes, campaign data , cross sell/upsell data. 

M
Meghana_NAuthor
Level 2
March 31, 2026

​@Harwinder-singh 

Thanks for your suggestions.

The product catalog is enterprise‑scale. -

  • Product ranges (parents): ~150–300
  • SKUs / variants (children): ~8,000–15,000
  • Digital assets (images, PDFs, line art): 20,000+

  • Typical SKU (most fields, 2–3 images) - ~7–9 KB

 

M
Meghana_NAuthor
Level 2
March 31, 2026

Adding to the above , I have the below four below options. Please suggest the one that is more feasible in this scenario -

  • Option 1: Build a cloud‑native importer on AEMaaCS (using custom jobs or Adobe App Builder) to ingest Salsify data and create/update Content Fragments via AEM APIs.

  • Option 2: Use AEM Content Fragment HTTP APIs directly from external services (Node/Java/Python) to programmatically create and maintain product CFs without relying on ACS Commons MCP.

  • Option 3: Implement an external/CI‑CD–driven ingestion pipeline that transforms PIM data outside AEM and syncs it into AEM using Content Fragment and Assets APIs.

  • Option 4: Skip persisting product data in AEM entirely and use a pure dynamic PDP approach where AEM templates render layouts and Sling Models fetch SKU data live from PIM APIs at request time.

Terms & ConditionsAccessibility statement

Loading footer...