Keep Product Media in Step With a PIM

Prerequisites

Before configuring a flow, identify the product identifier shared by the PIM and media platform. Also name the owner of product data, the owner of media renditions, and the people who will handle records that cannot be matched automatically.

For Akeneo, you need access to its connection details and the relevant product and asset fields. Start with one product that has valid media, one product with no media, and one deliberately broken association. Those three cases expose different outcomes before the flow reaches the full catalogue.

Steps

1. Write the direction-of-truth contract first

   Make the PIM authoritative for product data: identifiers, product associations, and the fields that describe the product. Make the media platform authoritative for source assets and the renditions derived from them. The PIM should receive the media reference it needs; it should not become a second place for editing rendition rules.

   This boundary matters because both systems can emit events and update metadata. Cloudinary’s guide to integration architecture, last updated August 16, 2026, documents bidirectional flows in which an event from either platform can cause a write to the other. If both sides treat the same field as authoritative, an update can be written back as another update and produce a loop.

   Record the contract as explicit field-level rules: which system may originate each value, which system receives a copy, and whether a received update is allowed to trigger another sync. If the team cannot answer those questions, do not configure a bidirectional flow yet. A one-way flow is the safer starting condition because it has one origin for each value.

2. Use the published Akeneo flow when its data model fits

   Akeneo is the common case for which a published MediaFlows sync flow exists; Cloudinary last updated that documentation on July 21, 2026. It includes manual sync, a structured-metadata trigger, and a scheduled retry for records still requiring a link. That makes an ordinary Akeneo connection a configuration exercise—connections, fields, triggers, and mappings—rather than a bespoke service.

   Do not confuse that PowerFlow with the old integration application. Cloudinary’s PIM integration catalogue, last updated February 10, 2026, says support for the legacy Akeneo PIM integration ended on August 29, 2024 and points users to MediaFlows instead.

   The published flow is the wrong answer when the PIM is not Akeneo or when the required matching and reconciliation rules cannot be expressed by its blocks. In that case, compare a hosted visual automation with a webhook handler before committing to custom code. The cost of the visual flow is constraint: unusual branching and state handling may eventually reach the point where no-code stops being enough.

3. Match assets on the product identifier, never the filename

   Put the PIM’s stable product identifier—commonly the SKU—into structured metadata on the media asset. Use that value as the join key. Filenames are the least stable attribute in a media library: editors rename them, exports replace them, and different products can receive files with similar names. A filename is useful for display, not identity.

   The published Akeneo flow builds an asset code from the SKU and Cloudinary asset ID, in the form {SKU}__{asset_id}. The SKU supplies the product relationship; the asset ID distinguishes multiple assets attached to the same product. This preserves the product match without pretending that one product can have only one image.

   Decide what happens when the identifier is absent, duplicated, or does not resolve to a PIM product. Route that record to an exception state rather than guessing from the filename. The cost is a queue that someone must clear, but that is cheaper than silently associating a valid image with the wrong product.

4. Configure the smallest flow that records its own state

   Connect the Akeneo account, retrieve its access token, read the product identifier and other required structured metadata, retrieve the asset’s secure URL, create the Akeneo asset, and mark the media record as linked only after the creation succeeds. Cloudinary’s sample uses states including Requires Link, Linked, and Requires Unlink.

   The state field is not decoration. It prevents a successful write from being treated as new unfinished work, makes linked and unlinked assets searchable, and gives the retry flow a precise set to inspect. Store the product identifier, asset family, attribute, and generated asset code needed by later link or unlink operations.

   Begin with the manual trigger when associations vary by asset or a person must confirm each link. Use the metadata-change trigger when the team already has a preparation step and changing the status is the deliberate handoff. If this is the first flow your team has operated, the block-by-block process in building a first media automation provides the relevant setup pattern.

5. Separate missing media from failed synchronization

   Define two different checks:

   • No image: the product has no media asset associated with its product identifier. There was nothing for the automation to send. This is a catalogue or content-production gap, not a sync failure.
   • Sync failed: a matching media asset exists and was eligible to run, but the destination was not updated successfully. This is the automation’s failure domain.

   Do not put both cases in one “missing image” report. A combined count cannot tell the content team how many products need photography or tell engineering how many attempted operations failed. It also encourages retries for records that have no source asset and therefore cannot succeed.

   Keep separate exception views or statuses. The no-image view starts from PIM products and asks whether a matching asset exists. The failed-sync view starts from eligible media assets and asks whether they reached the linked state. Only the second group belongs in the automated retry path.

6. Choose sync frequency from the operation budget

   Sync frequency is a cost decision. A per-change trigger on a large catalogue generates far more operations than a scheduled reconciliation because every qualifying change starts work immediately. A scheduled flow searches for outstanding records at intervals and processes the results together. The supplied evidence contains no verified price or operation count, so do not label either choice cheaper without measuring your own catalogue.

   Use per-change triggering when the business condition requires updates shortly after an editor marks an asset ready and the expected change volume fits the operation budget. Its cost is repeated execution during bursts and more opportunities for transient changes to trigger work.

   Use scheduled reconciliation when delay is acceptable, changes arrive in bursts, or the team wants a bounded operating window. Its cost is staleness between runs. Cloudinary’s sample includes a scheduled search for assets in requires_link, iteration over those assets, and a report of processed records. A schedule also works as a retry safety net behind an event-driven primary flow.

   Measure qualifying changes over a representative period, count the blocks or operations each route executes, and compare that total with the acceptable delay. Without those inputs, “real time” is a preference rather than a requirement.

7. Test identity, absence, failure, and recovery separately

   Run the valid product and confirm that the resulting PIM association uses the product identifier and reaches the linked state. Rename the source file and rerun the check; the relationship should still resolve through the product identifier.

   Run the product with no asset and confirm that it appears only in the no-image view. Then run the deliberately broken association and confirm that it remains outside the linked state, appears in the failed-sync view, and is eligible for retry. Finally, correct the association and verify that reconciliation links it once without causing a write-back loop.

Expected result

Done means the PIM remains authoritative for product records, the media platform remains authoritative for renditions, and every synchronized asset is joined by product identifier rather than filename. Products without media are reported separately from attempted syncs that failed. Successful records have an explicit linked state, and failed records enter a measured retry schedule whose frequency reflects the catalogue’s operation budget.