AEMaaCS: DAM Asset Change Notifications to 3rd party via AEM Eventing + Runtime Action

Hello ​@samr99530769 

Although both Assets View and Admin View access the same DAM content, Adobe documentation does not provide a formal statement that Adobe I/O asset events will fire identically from both UIs for all operations.

For that reason, we would not recommend finalizing the design on that assumption alone. The recommended approach is to validate the required asset lifecycle events from each UI and, where possible, standardize on a single authoring path for predictable event behavior.

Content Fragments should be treated as a separate validation area because you are stored as assets but are documented as a Sites feature.
Reference:

1. Switch views in AEM Assets
2. Content Fragments
3. Working with Content Fragments

We recommend validating at minimum: upload/create, metadata edit, binary replace, move/rename, delete, and restore, across each UI your authors will use.

Hi ​@samr99530769 ,

Sarthak’s guidance is accurate and the validation recommendation is the right approach before going to production. To add some practical context from building similar AEM Eventing integrations.

The core reason the behavior differs between Assets View and Admin View is that the two UIs interact with the DAM repository through different code paths even though they share the same underlying JCR content. Assets View is built on a modern microservices layer that uses the AEM Assets API directly, while Admin View operations go through the classic Sling request processing layer. Both ultimately write to the same repository nodes which is why you see the same content, but the event emission happens at different points in those code paths which can lead to subtle differences in which events fire, when they fire, and what the event payload contains.

For your use case covering images, documents, Content Fragments, and videos the most important events to validate across both UIs are asset created, asset updated, asset metadata updated, asset deleted, and asset moved. The asset updated event in particular behaves differently between the two UIs because Assets View batches some metadata updates that Admin View processes individually, which can affect how many events your Runtime action receives for what appears to be a single author operation.

Content Fragments are the most important to test separately as Sarthak noted. CF create and update events come through the Sites eventing channel rather than the Assets eventing channel even though CFs live in the DAM. If your Runtime action is only subscribed to asset events you will miss CF operations entirely. Make sure your I/O Events registration includes the Content Fragment event types separately from the DAM asset types.
 

One practical thing to build into your Runtime action from the start is idempotency handling. Because both UIs can fire events in bursts during bulk operations, your action should deduplicate based on asset ID and timestamp before forwarding to your third party system to avoid duplicate notifications.