External DAM / PIM patterns
Who this page is for
| Audience | Why it matters to you |
|---|---|
| Architects | Mastering decisions |
| Backend engineers | Sync builders |
First decision: who is the master?
| Data | Master | AEM's role |
|---|---|---|
| Brand assets in a corporate brand portal | External DAM | Consumer (sync or link) |
| Product facts (PHI plan premiums, benefit rules) | PIM/policy admin system | Consumer — render, never edit |
| Web-specific imagery, page content | AEM | Master |
Dual-mastering (editable in both) is the failure mode; every field has exactly one system of record, and AEM components render read-only what they don't own.
External DAM patterns
| Pattern | Mechanism | Trade |
|---|---|---|
| Sync-in | Scheduled/event-driven import into /content/dam (with source ID metadata) | Full AEM feature use (renditions, references); storage ×2; sync jobs to operate |
| Link-out | Components reference external URLs (connector/picker UI) | No duplication; but no local renditions, availability coupled to external CDN, cache/invalidations external |
| Hybrid | Sync the curated "approved for web" subset only | Usual enterprise answer |
Sync-in rules: imports carry source-system ID + version in metadata (idempotent re-sync, provenance), deletions propagate as unpublish-then-report (never silent delete of referenced assets — check references first), and the DAM governance schema applies to imports too.
PIM/product-data patterns
Product facts follow the sync-to-content pattern (caching external data): scheduled import into Content Fragments (one CF per plan, model mirrors the PIM contract), authors compose experience around them, components render CF data read-only. Benefits: authoring UX sees real data, publish tier renders repo-local data (no render-path calls), and premium changes are a re-sync + replication, fully auditable.
Escalations: real-time pricing (per-user quotes) is not sync-able — that's the client-side/gateway pattern (integration placement).