Exploring Asset Lifecycle Management Approaches for Bynder and Optimizely SaaS CMS

Note: This is Part 3 of our Bynder integration series. For setup and filtering prerequisites, see Part 1 and Part 2.

Introduction

In my previous article, I explored approaches for controlling asset ingestion from Bynder into Optimizely SaaS CMS through metadata-based filtering.

Filtering assets before they enter the platform is an important first step, but in many enterprise DAM integrations, it only addresses part of the lifecycle.

Once assets have been synchronized, a different set of challenges begins to emerge:

• What happens when an asset's metadata changes after synchronization?
• How should previously synchronized assets be handled when they no longer meet business rules?
• How can organizations govern assets across Development, Staging, and Production environments?
• How can teams safely determine whether an asset is still being used before removing it?
• When does it make sense to extend an existing integration versus building a completely custom connector?

These questions gradually shift the conversation from asset synchronization to asset lifecycle management.

This article explores some architectural considerations and potential approaches that may help address those challenges.

The Asset Lifecycle Challenge

Synchronization is rarely a one-time event. Assets constantly evolve throughout their lifetime. 
A typical lifecycle might look something like this:

For example:

• An image may no longer belong to a target environment.
• An image may become hidden through metadata changes.
• An image may remain inside Optimizely despite no longer being available within Bynder.
• An image may still be actively referenced by content authors even though business rules indicate it should be removed.

These scenarios introduce governance challenges that extend well beyond initial synchronization.

Orphaned Assets

One scenario that stood out during evaluation was the possibility of orphaned assets.

Consider the following sequence:

From the perspective of the synchronization process, the asset has effectively disappeared.

The integration can no longer retrieve information about the asset.

However, the existing record may continue to exist inside Optimizely.

Over time, these records could accumulate, creating a divergence between the source DAM and the target CMS repository.

While this may not create an immediate problem, organizations with large asset libraries may eventually start asking:

• Which assets are still valid?
• Which assets should still exist?
• Which assets are no longer governed by the current synchronization rules?

These questions become increasingly important as repositories grow.

Environment Governance

Another consideration involves environment ownership.

Most enterprise implementations maintain separate environments:

However, DAM platforms are often centrally managed.

A common scenario looks something like this:

Without additional controls, all environments may receive identical assets.

This can introduce several concerns:

• Increased storage consumption
• Cluttered non-production environments
• Difficult testing scenarios
• Confusion around environment-specific assets

Suggested Environment Metadata Approach

One possible approach is introducing an additional metadata property or use tags inside Bynder.

Example:

"website-environment" metadata property with possible values:

This metadata could travel alongside normal asset synchronization and provide additional governance information to downstream systems.

Suggested Visibility Configuration

Unlike visibility-based filtering rules, this property/tags does not need to setup separate profiles/users and any explicit filtering rules.

The goal is not to hide assets. The goal is to communicate intent.

Why Environment Metadata May Be Valuable

Without environment metadata, every environment receives same assets.

With environment metadata, environment validation processes can be setup to stop storing assets those are not required in the environment.

This approach may provide a lightweight governance layer without introducing separate DAM repositories, separate taxonomies, or separate synchronization configurations.

Architectural Note

The workflow described in the following sections represents an architectural approach that emerged during the evaluation of lifecycle management challenges associated with large-scale DAM integrations.

While the individual platform capabilities required for this model—including Bynder webhooks, permanent access tokens, Optimizely Graph/Content Management APIs, and Optimizely Graph reference queries— are available today, the complete end-to-end workflow has not yet been fully validated in a production implementation.

The intent of this article is to explore a potential governance pattern and discuss its trade-offs rather than present a proven production architecture.

Exploring an Event-Driven Governance Model

One approach that appears interesting from an architectural perspective is introducing a webhook-driven governance workflow.

For simplicity, this article assumes the webhook endpoint is deployed inside the frontend nextjs application.

In practice, the webhook could be hosted anywhere:

• Next.js API Route
• Azure Function
• AWS Lambda
• Google Cloud Function
• Dedicated Middleware Service
• Integration Platform

The location itself is less important than the validation process being executed.

At a high level:

Bynder Calls Webhook  >  Webhook Receives event  >  Validation Logic  >  Asset remains or Deleted

 

Gate 1: Visibility Validation

The first validation stage could determine whether the asset remains visible to the synchronization account.
Note: Use permanent token assigned for the synchronization account.

Conceptually:

The objective is not necessarily to delete the asset immediately. Instead, the objective is to determine whether the asset still falls within the intended synchronization scope. If visibility has changed, additional evaluation may be required.

Gate 2: Environment Validation

The second validation stage could evaluate environmental ownership.

Example workflow:

This allows governance decisions to be made without requiring separate DAM repositories.

An asset intended exclusively for Production could potentially be excluded from lower environments while remaining available in Production.

Gate 3: Reference Validation

1. Full-text search — Query Content using _fulltext: { match: "asset-id" } to search across all indexed content. Quick but imprecise — depends on how asset IDs are indexed.
2. Schema introspection + targeted queries — Use GraphQL introspection to discover all content types with reference-type fields, then query each one. More thorough but requires automation to be practical.
3. Content Management API enumeration — Use the CMS REST API to walk content and check references programmatically.

Deleting Assets from Optimizely

Once an asset has been evaluated, a governance process may decide that removal should occur.

Important questions include:

• Is the asset still visible?
• Is the asset assigned to the current environment?
• Is the asset actively referenced?
• Should the asset remain synchronized?

If all validation checks indicate removal is appropriate, a deletion request could be submitted through the Content Management API.

An important distinction exists between: Soft Delete vs Hard Delete

For lifecycle-management scenarios, hard deletion may be more relevant because the objective is often to reduce repository footprint rather than move content into a recycle state.

This would permanently remove the asset rather than transferring it into a recycle bin.

Monitoring and Troubleshooting

Whenever automated deletion is introduced, observability becomes extremely important.

Questions that operations teams will eventually ask include:

• Asset identifier
• Event timestamp
• Validation results
• Environment
• API response
• Deletion outcome

Monitoring Deletion Activity

One area that would require validation during implementation is how deletion activity can be monitored within the platform.

A potential starting point would be reviewing:

• Search & Navigation portal logs
• Graph activity logs
• API diagnostics
• Application telemetry
• Hosting platform logs

This would help determine whether delete operations are executing successfully and provide additional visibility during troubleshooting.

Extending the Existing Integration vs Building a Custom Connector

A natural question that often emerges is:

• If lifecycle governance is required, should we simply build a custom connector?

The answer depends on organizational priorities.

For many organizations, extending an existing integration with additional governance capabilities may represent a more balanced approach than replacing the synchronization engine altogether.

Assumptions and Validation Status

The approaches discussed throughout this article are based on architectural evaluation and platform capability analysis rather than a fully validated production implementation.

At the time of writing, the proposed event-driven webhook model remains an architectural concept that appears technically achievable based on the currently available capabilities of:

• Bynder webhooks
• Bynder permanent tokens
• Optimizely Content Management /Graph APIs
• Optimizely Graph reference lookups
• Standard event-driven integration patterns

However, several areas would benefit from additional validation before adoption within a production environment:

• Large-scale webhook processing behavior
• API rate limiting and throttling characteristics
• Long-running operational reliability
• Deletion timing and synchronization race conditions
• Monitoring and alerting strategies
• Reconciliation requirements for lost events
• Long-term maintenance implications

As with any architectural pattern, organizations should conduct their own validation, performance testing, and operational reviews before implementing the approach within production workloads.