Blog posts by Vipin Banka | Learnings & Insights2026-07-31T03:15:37.0000000Zhttps://world.optimizely.com/blogs/vipin-banka--learnings--insights/Optimizely WorldFlat or Nested? Weighing Your Content Modeling Options in Optimizely SaaS CMS<p>When building a headless site on Optimizely SaaS CMS, one of the earliest and most critical design milestones your team will face is defining your <strong>content model</strong>.</p>
<p>Unlike traditional monolithic setups where visual layout often dictates data structure, headless modeling requires you to design a clear, reusable contract between two very different groups of people: your <strong>content authors</strong> (working in the CMS UI) and your <strong>developers</strong> (writing front-end components).</p>
<p>Because developers are trained to eliminate duplicate code (the "DRY" principle), they often instinctively design highly complex, nested, or consolidated data structures. Authors, on the other hand, require flat, intuitive, and self-explanatory editing interfaces.</p>
<p>When these two instincts collide, tension arises.</p>
<p>Below, we’ll walk through a common, real-world scenario—modeling standard videos versus gated lead-generation videos—and lay out three valid modeling options, complete with their architectural trade-offs, so your team can make a well-informed choice.</p>
<hr />
<h2>The Scenario: One Concept, Two Realities</h2>
<p>Let's say your site needs to support videos in two very different business contexts:</p>
<ol class="tight">
<li>
<p><strong>Standard Video:</strong> An editorial or informational video with autoplay, looping, and visual player controls.</p>
</li>
<li>
<p><strong>Gated Video:</strong> A lead-generation asset that plays a brief preview, pauses at a specific timestamp, and displays an email capture form synced automatically with an external Marketing Automation Platform (MAP).</p>
</li>
</ol>
<table style="border-collapse: collapse; width: 100%; border-width: 1px; border-style: solid;">
<tbody>
<tr>
<td style="padding: 10px; text-align: left; vertical-align: top; border-width: 1px; border-style: solid;">
<p><strong>Feature</strong></p>
</td>
<td style="padding: 10px; text-align: left; vertical-align: top; border-width: 1px; border-style: solid;">
<p><strong>Standard Video</strong></p>
</td>
<td style="padding: 10px; text-align: left; vertical-align: top; border-width: 1px; border-style: solid;">
<p><strong>Gated Video</strong></p>
</td>
</tr>
<tr>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p><strong>Author sets</strong></p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p>Video file, Poster image, Title, Autoplay toggle, Loop toggle, Show controls</p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p>Video file, Poster image, Title</p>
</td>
</tr>
<tr>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p><strong>Sourced from MAP</strong></p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p>Not applicable</p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p>Form ID, Gate Timestamp (seconds to trigger form)</p>
</td>
</tr>
<tr>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p><strong>Front-end behavior</strong></p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p>Continuous playback, native player controls</p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p>Pauses playback at Gate time and overlays lead capture form</p>
</td>
</tr>
</tbody>
</table>
<p>To model this, your team has three distinct structural approaches to consider. Let's look at the trade-offs of each.</p>
<hr />
<h2>Option 1: The Consolidated "Mega-Block" (All Fields in One Type)</h2>
<p>This approach creates a single, highly flexible content type—such as VideoComponent—containing every possible property. You then rely on the author's training (or inline help text) to know which fields to fill.</p>
<pre class="code-block"><code>Consolidated Block: VideoComponent
├── VideoFile
├── PosterImage
├── Title
├── Autoplay (Fill only for Standard)
├── Loop (Fill only for Standard)
├── ShowControls (Fill only for Standard)
├── FormId (Fill only for Gated)
└── GateTimestamp (Fill only for Gated)</code></pre>
<h3>The Trade-Offs</h3>
<ul class="tight">
<li>
<p><strong>Pros:</strong></p>
<ul class="tight">
<li>
<p><strong>Simple Setup:</strong> Only one content type to define, register, and sync to the CMS.</p>
</li>
<li>
<p><strong>Single Component:</strong> Developers maintain just one straightforward React component with simple conditional rendering.</p>
</li>
</ul>
</li>
<li>
<p><strong>Cons:</strong></p>
<ul class="tight">
<li>
<p><strong>Author Cognitive Load:</strong> Authors are forced to look at "dead fields." An editor adding a gated marketing video must mentally ignore Autoplay, Loop, and Controls.</p>
</li>
<li>
<p><strong>Validation Gaps:</strong> You cannot easily make fields like FormId required for gated videos without making them required for standard videos too, risking incomplete data.</p>
</li>
</ul>
</li>
</ul>
<hr />
<h2>Option 2: The Nested "Wrapper Block" (Composition via Content Area)</h2>
<p>This approach seeks to avoid database field duplication by pulling the shared properties (<strong>VideoFile</strong>, <strong>PosterImage</strong>, and <strong>Title</strong>) into a parent <strong>VideoItem </strong>block. This block then contains a nested Content Area where the author inserts a secondary "extension block" containing the specific properties.</p>
<pre class="code-block"><code>Parent Block: VideoItem
├── VideoFile
├── PosterImage
├── Title
└── Content Area (Allows only StandardProperties OR GatedProperties)</code></pre>
<h3>The Trade-Offs</h3>
<ul class="tight">
<li>
<p><strong>Pros:</strong></p>
<ul class="tight">
<li>
<p><strong>Strictly "DRY" Database Schema:</strong> The base fields are declared exactly once, preventing schema duplication.</p>
</li>
<li>
<p><strong>Modularity:</strong> You can reuse the "Standard" or "Gated" property blocks in other components across the system.</p>
</li>
<li>
<p><strong>Configurable guardrails:</strong> Content Areas are not a free-for-all. Built-in validation fields let you constrain them declaratively—<strong>allowedTypes </strong>/ <strong>restrictedTypes </strong>restrict exactly which extension types can be dropped in, and <strong>maxLength: 1</strong> caps the area to a single item—so wrong-type and duplicate insertions are preventable without any custom code.</p>
</li>
</ul>
</li>
<li>
<p><strong>Cons:</strong></p>
<ul class="tight">
<li>
<p><strong>Editing Friction:</strong> Authors must execute a two-step process to build a single video. They fill out the parent, click "Create New Block" inside the Content Area, and then fill out the child block—slower than picking one flat type up front.</p>
</li>
<li>
<p><strong>The "empty wrapper" gap:</strong> While <strong>allowedTypes </strong>and <strong>maxLength </strong>handle type and cardinality, enforcing a strict <em>minimum</em> of one item is not cleanly supported for content areas—so an author can still save an empty wrapper with no extension inside.</p>
</li>
<li>
<p><strong>GraphQL Query Noise:</strong> Even when correctly constrained, every query to fetch a video must navigate a nested fragment structure, increasing the payload and query complexity compared to a flat type.</p>
</li>
</ul>
</li>
</ul>
<hr />
<h2>Option 3: The Split-Type "Symmetrical" Pattern (Recommended)</h2>
<p>This approach splits the concept into two distinct, flat content types: <strong>StandardVideo </strong>and <strong>GatedVideo</strong>. The author's choice of which component to insert in their page layout <em>is</em> the disambiguation.</p>
<p>To keep things clean, we use Optimizely's built-in features to resolve the duplication: <strong>Property Groups</strong> for authors, and <strong>SDK Contracts</strong> for developers.</p>
<pre class="code-block"><code>Standard Video (Type 1)
├── [Video Settings Group] ← via SDK Contract
│ ├── VideoFile
│ ├── PosterImage
│ └── Title
└── [Player Options Group]
├── Autoplay, Loop, ShowControls
Gated Video (Type 2)
├── [Video Settings Group] ← via SDK Contract
│ ├── VideoFile
│ ├── PosterImage
│ └── Title
└── [Lead Capture Group]
├── FormId, GateTimestamp</code></pre>
<h3>The Trade-Offs</h3>
<ul class="tight">
<li>
<p><strong>Pros:</strong></p>
<ul class="tight">
<li>
<p><strong>Excellent Author UX:</strong> Editors see only the fields that are directly relevant to what they are creating. No noise, no confusion, and the choice happens up front in a single step.</p>
</li>
<li>
<p><strong>Precise Validation:</strong> You can make <strong>FormId </strong>strictly required on Gated Videos and <strong>VideoFile </strong>required on both, with no overlaps—and no "empty wrapper" edge case to guard against.</p>
</li>
<li>
<p><strong>Evolvable Schemas:</strong> If you need to add an "External Tracker ID" to Gated Videos later, you add it to the Gated type. The Standard Video type remains completely untouched, preventing regressions.</p>
</li>
<li>
<p><strong>Flat GraphQL queries:</strong> Each type resolves directly, with no nested content-area fragment to traverse.</p>
</li>
</ul>
</li>
<li>
<p><strong>Cons:</strong></p>
<ul class="tight">
<li>
<p><strong>Minor Code Duplication:</strong> In some architectures, this might mean registering two types instead of one (though Optimizely's SDK makes this incredibly clean, as shown below).</p>
</li>
</ul>
</li>
</ul>
<hr />
<h2>Implementing Option 3 Cleanly with the Content JS SDK</h2>
<blockquote>
<p>⚠️ <strong>Implementation Disclaimer:</strong> <em>The following code snippets are illustrative implementations demonstrating the structure and APIs of the </em><strong>@optimizely/cms-sdk</strong><em>. Depending on your active SDK version, environment settings, and target packages, always verify the exact properties, imports, and field parameters in your sandbox prior to deploying content types to production.</em></p>
</blockquote>
<h3>1. Define a Shared Contract in Code</h3>
<p>The SDK's <strong>contract()</strong> function lets you declare the shared fields once. It keeps your codebase DRY, but merges the properties directly into each schema under the hood so authors get a flat, non-nested editor form:</p>
<pre class="code-block"><code class="language-ts">// src/contracts/VideoBaseContract.ts
import { contract } from '@optimizely/cms-sdk';
export const VideoBaseContract = contract({
key: 'VideoBase',
properties: {
videoFile: { type: 'contentReference', allowedTypes: ['_video'], required: true },
posterImage: { type: 'contentReference', allowedTypes: ['_image'], required: true },
title: { type: 'string', required: true },
},
});</code></pre>
<h3>2. Extend the Contract in Your Content Types</h3>
<p>Both content types simply extend our base contract:</p>
<pre class="code-block"><code class="language-ts">// src/components/StandardVideo.ts
export const StandardVideoContentType = contentType({
key: 'StandardVideo',
baseType: '_component',
extends: VideoBaseContract, // <-- Merges shared fields
properties: {
autoplay: { type: 'boolean', group: 'playerOptions' },
loop: { type: 'boolean', group: 'playerOptions' },
showControls: { type: 'boolean', group: 'playerOptions' },
},
});
// src/components/GatedVideo.ts
export const GatedVideoContentType = contentType({
key: 'GatedVideo',
baseType: '_component',
extends: VideoBaseContract, // <-- Merges shared fields
properties: {
formId: { type: 'string', group: 'leadCapture' },
gateTimestamp: { type: 'integer', group: 'leadCapture' },
},
});</code></pre>
<h3>3. Resolve to a Single React Component</h3>
<p>Here is the developer's favorite trick: even though we have two schemas in the CMS, <strong>we can map them both to a single React component.</strong></p>
<p>In our registry setup, we point both type keys to our <strong><VideoItem /></strong> component. The component inspects <strong>__typename</strong> (always supplied by Optimizely Graph) to decide how to render:</p>
<pre class="code-block"><code class="language-ts">// src/app/layout.tsx — Map both keys to the same component
initReactComponentRegistry({
resolver: {
StandardVideo: VideoItem,
GatedVideo: VideoItem,
},
});
// src/components/VideoItem.tsx — One entry, two layouts
export default function VideoItem({ content }: Props) {
if (content.__typename === 'GatedVideo') {
return <GatedVideoView content={content} />; // Typed as GatedVideoProps
}
return <StandardVideoView content={content} />; // Typed as StandardVideoProps
}</code></pre>
<hr />
<h2>Conclusion: Choosing What's Right for Your Team</h2>
<p>There is rarely a single "correct" answer in software architecture—only choices and their consequences.</p>
<ul class="tight">
<li>
<p>If your team is very small, your content needs are highly fluid, and you prioritize a rapid setup above all else, <strong>Option 1 (The Consolidated Block)</strong> might serve you well.</p>
</li>
<li>
<p>If your design system relies heavily on composable, modular sub-assemblies and your editors are comfortable with multi-step nesting, <strong>Option 2 (The Nested Wrapper)</strong> offers high structural reuse.</p>
</li>
<li>
<p>If you prioritize editor productivity, robust validation, and clean GraphQL queries, <strong>Option 3 (The Split-Type Pattern)</strong> combined with the SDK's single component routing gives you the best of both worlds: flat schemas for authors, and type-safe, DRY code for developers.</p>
</li>
</ul>
<p>By laying these options on the table, your team can align on a modeling philosophy that matches your technical maturity and authoring workflows.</p>
<hr />
<p><em>Resources: </em><a href="https://github.com/episerver/content-js-sdk/tree/main/docs"><em>Content JS SDK documentation</em></a><em> · </em><a href="https://docs.developers.optimizely.com/content-management-system/v1.0.0-CMS-SaaS/docs/content-modeling-saas"><em>Optimizely content modeling principles</em></a><em> · </em><a href="https://docs.developers.optimizely.com/content-management-system/v1.0.0-CMS-SaaS/docs/content-base-types-saas"><em>Content base types</em></a></p>2026-07-31T03:15:37.0000000ZBlog postParallel Development in Optimizely CMS SaaS: Shifting to a Schema Migration Mindset<p> </p>
<p><em>Part 3 of the Parallel Development series.</em></p>
<p>The branch-scoped push script from <a href="/link/60050e9906014446bb28143b0ca1b0c2.aspx">Part 1</a> works. Run it on a feature branch where you've touched a handful of independent content types and it does exactly what it promises — pushes only your changes, leaves your teammate's work untouched, no <strong>--force</strong> required.</p>
<p>For most of your day-to-day work, that's enough. The majority of content type changes are leaf changes: you added a field to a page, you tweaked a block, you updated a template. The script handles all of those cleanly.</p>
<p>But as soon as you start moving past basic, isolated components and build toward a real content model—with custom contracts, shared property groups, and complex validation rules—the landscape changes. The script still works, but running selective push against a full, production-grade schema teaches you a few things worth mapping out before you hit them cold. None of this is a flaw in the selective push approach. These dependency cases exist in any code-first workflow with the CLI, whether you push selectively or all at once. What changes is whether you walk into them knowing what's happening, or whether you spend an afternoon confused at an API rejection.</p>
<p>This post maps the five hidden dependency cases, shows what each looks like in code, and proposes a repo structure plus a reviewable push workflow that makes them more manageable. These are starting points and open questions — not a finished solution. We'd genuinely like to hear how other teams are thinking about this.</p>
<hr />
<h2>First: "Why not just always full push?"</h2>
<p>It's the fair question, and worth answering before anything else — because if full push were always fine, none of this would matter.</p>
<p>Full push is authoritative and safe <em>against a clean, canonical branch</em>. That's exactly why it's the right tool for your CI/CD pipeline pushing from <strong>main</strong>. But on a <strong>shared development instance where several people have unmerged work</strong>, full push is the opposite of safe: it syncs your <em>entire</em> local model, including stale or half-built types, over whatever your teammates have pushed. That's the collision Part 1 set out to solve.</p>
<p>And when the CLI suggests <strong>--force</strong>? That's not a fix. It's the CLI telling you the remote already has changes you're about to overwrite. The correct response is to <strong>sync with your team</strong>, not to force through. Force is how one developer silently clobbers another's content types.</p>
<p>So the real trade-off isn't "selective push (hard) vs full push (easy)." It's:</p>
<ul class="tight">
<li>
<p><strong>Independent leaf changes (the 80%)</strong> — selective push is fully automatic and strictly better. No contest.</p>
</li>
<li>
<p><strong>The five dependency cases</strong> — selective push <em>still</em> beats full push on a shared instance, because a scoped-but-complete push includes what's needed and touches nothing else. The catch is you have to know what "complete" means. That's what this article tries to make knowable.</p>
</li>
<li>
<p><strong>Key renames and deletions</strong> — these genuinely are "stop and coordinate" moments. The honest value here isn't a clever script; it's <em>recognising</em> you're in one, so you sync with the team and run a deliberate full push instead of forcing blindly.</p>
</li>
</ul>
<p>That's the frame for everything below. This isn't about avoiding full push forever — it's about knowing which situation you're in.</p>
<hr />
<h2>The Five Hidden Dependencies</h2>
<p>In Optimizely CMS SaaS, we've identified five distinct cases where a change to one file creates a dependency that requires other files to be pushed in the same payload. Before we look at how to handle them, here is the quick map of the territory:</p>
<ol class="tight">
<li>
<p><strong>Contract changes</strong> — Modifying an interface pulls in all content types implementing it.</p>
</li>
<li>
<p><strong>Property group changes</strong> — Renaming or removing a group key affects every content type assigned to it.</p>
</li>
<li>
<p><strong>Component embeds</strong> — Schema shifts on a component affect any content type using them as typed properties.</p>
</li>
<li>
<p><strong>Validation constraints</strong> — Changes to referenced type keys break <strong>allowedTypes</strong> or <strong>restrictedTypes</strong> in other files.</p>
</li>
<li>
<p><strong>Key renames</strong> — A key value change is a destructive delete-and-create that orphans content and breaks external references.</p>
</li>
</ol>
<p>For each case, the "how to handle it" notes reflect our own thinking and what seems reasonable — not tested playbooks. Your project's structure and conventions will change what actually works.</p>
<hr />
<h2>Case 1 — Contract change → all implementing types</h2>
<p>Contracts define a shared set of properties that multiple content types implement. Add a field to a contract, and every implementing type has a stale resolved schema on the server — because that field is now part of their schema too, whether they declared it explicitly or not.</p>
<p>This is transitive. If Contract A is implemented by Contract B, and Contract B is implemented by five page types, a change to Contract A means all six need to be in the same push.</p>
<h3>Why isolated contract pushes fail</h3>
<p>The temptation is to slice pushes into layers — a "foundation" config that covers contracts, a "types" config that covers pages and blocks. Different concerns, different cadence. The logic is sound.</p>
<p>Then you try it on a live instance where types already implement the contract:</p>
<pre class="code-block"><code class="language-bash"># Fails if any content type already implements the contract on the target instance
npx @optimizely/cms-cli@latest push --config optimizely.config.foundation.mjs</code></pre>
<p>The CLI errors out. The API rejects the payload.</p>
<p>Based on observed behaviour, when a contract changes on the server, the CMS appears to immediately recompile the fully resolved schema of every implementing type. If those types aren't in the same push payload, the API rejects the whole operation rather than leave the instance in a half-compiled state. This is the right call — it's protecting you. But it means contracts and their implementers can't travel separately once the contract is applied.</p>
<p>📖 <a href="https://docs.developers.optimizely.com/content-management-system/v1.0.0-CMS-SaaS/docs/create-contracts">Create contracts</a></p>
<blockquote>
<p><strong>Note on code examples:</strong> The JSON and TypeScript shapes shown throughout this article are illustrative of the concepts. Always check the current CLI <strong>--help</strong> output and the <a href="https://docs.developers.optimizely.com/content-management-system/v1.0.0-CMS-SaaS/docs/manage-content-types-using-the-rest-api">REST API reference</a> for exact syntax on your version.</p>
</blockquote>
<pre class="code-block"><code class="language-json">// Contract — POST https://api.cms.optimizely.com/v1/contenttypes
{
"key": "categorizable",
"displayName": "Categorizable",
"properties": {
"category": { "type": "string", "displayName": "Category" },
"tags": { "type": "array", "displayName": "Tags", "items": { "type": "string" } }
}
}
// Content type implementing the contract
// Adding a field to 'categorizable' above means this type must be in the same push
{
"key": "articlePage",
"baseType": "_page",
"contracts": ["categorizable"],
"properties": {
"title": { "type": "string", "displayName": "Title" },
"body": { "type": "richText", "displayName": "Body" }
}
}</code></pre>
<blockquote>
<p><strong>One possible approach:</strong> Scan all content-type files for any import or string reference to the changed contract's file name, and include matches in the push set. Whether that works reliably depends on how consistently your codebase names and imports contracts — a loosely structured project may need a more explicit dependency map. We haven't found a clean universal answer here.</p>
</blockquote>
<hr />
<h2>Case 2 — Property group change → all types referencing that group</h2>
<p>Property groups are defined in <strong>optimizely.config.mjs</strong> via <strong>buildConfig</strong> and referenced by <strong>key</strong> inside property definitions. Change or remove that key, and any type that assigns properties to it fails validation.</p>
<p>📖 <a href="https://docs.developers.optimizely.com/content-management-system/v1.0.0-CMS-SaaS/docs/property-groups-saas">Property groups</a></p>
<pre class="code-block"><code class="language-javascript">// optimizely.config.mjs
import { buildConfig } from '@optimizely/cms-sdk';
export default buildConfig({
components: ['./src/content-model/**/*.tsx'],
propertyGroups: [
{ key: 'seo', displayName: 'SEO Settings', sortOrder: 10 }
// Rename 'seo' here → every type referencing this key must be re-pushed
]
});</code></pre>
<pre class="code-block"><code class="language-json">// PATCH https://api.cms.optimizely.com/v1/contenttypes/articlePage
{
"key": "articlePage",
"baseType": "_page",
"properties": {
"metaTitle": { "type": "string", "displayName": "Meta Title", "group": "seo" },
"metaDescription": { "type": "string", "displayName": "Meta Description", "group": "seo" }
}
}</code></pre>
<p>Rename the group key without re-pushing <strong>articlePage</strong> and its <strong>metaTitle</strong> / <strong>metaDescription</strong> properties now point to a group that doesn't exist on the instance.</p>
<blockquote>
<p><strong>One possible approach:</strong> Diff <strong>optimizely.config.mjs</strong>, extract changed group keys, and search content-type files for those strings. Since the config change is usually deliberate and visible in review, this might be something you handle at review time rather than automating — though what's right depends entirely on your team's workflow and how often these keys change.</p>
</blockquote>
<hr />
<h2>Case 3 — Component used as a typed property → the embedding type</h2>
<p>A <strong>_component</strong> content type can be declared as a fixed typed property on another content type — not just dropped into a content area at runtime, but <em>declared</em> in the schema as a property of that specific type. Optimizely Graph registers both <strong>TeaserBlock</strong> (standalone) and <strong>TeaserBlockProperty</strong> (when embedded as a schema property) to support this.</p>
<p>When the component's schema changes, the type that embeds it is resolving a shape that has shifted.</p>
<p>📖 <a href="https://docs.developers.optimizely.com/content-management-system/v1.0.0-CMS-SaaS/docs/content-modeling-saas-graph">Content modeling — content properties</a> · <a href="https://docs.developers.optimizely.com/content-management-system/v1.0.0-CMS-SaaS/docs/content-types-saas">Define content types</a></p>
<pre class="code-block"><code class="language-json">// The component — POST https://api.cms.optimizely.com/v1/contenttypes
{
"key": "teaserBlock",
"baseType": "_component",
"properties": {
"heading": { "type": "string", "displayName": "Heading" },
"image": { "type": "contentReference", "displayName": "Image" }
// Add a new required field here → homePage below must be in the same push
}
}
// A page declaring the component as a typed property
{
"key": "homePage",
"baseType": "_page",
"properties": {
"hero": { "type": "content", "displayName": "Hero Teaser", "contentType": "teaserBlock" }
}
}</code></pre>
<blockquote>
<p><strong>One possible approach:</strong> Scan content-type files for references to the changed component's name or key. The tricky part is distinguishing a typed schema embed from a regular rendering import — a flat folder makes this ambiguous, which is part of why the folder structure below is worth considering.</p>
</blockquote>
<hr />
<h2>Case 4 — allowedTypes / restrictedTypes references → the referencing type</h2>
<p><strong>allowedTypes</strong> and <strong>restrictedTypes</strong> are validation constraints on <strong>content</strong> and <strong>contentReference</strong> properties. They name other types <strong>by their key</strong>. That reference is invisible to a git diff.</p>
<p>📖 <a href="https://docs.developers.optimizely.com/content-management-system/v1.0.0-CMS-SaaS/docs/content-property">Content property — allowedTypes</a> · <a href="https://docs.developers.optimizely.com/content-management-system/v1.0.0-CMS-SaaS/docs/content-types-saas">Define content types</a></p>
<pre class="code-block"><code class="language-json">// PATCH https://api.cms.optimizely.com/v1/contenttypes/landingPage
{
"key": "landingPage",
"baseType": "_page",
"properties": {
"relatedContent": {
"type": "contentReference",
"displayName": "Related Content",
"allowedTypes": ["articlePage", "blogPage"]
}
}
}
// If 'blogPage' is renamed to 'blogPostPage' —
// git diff shows BlogPage.tsx changed
// git diff does NOT show landingPage.tsx changed
// but landingPage now references a key that doesn't exist</code></pre>
<p>Adding a <em>new</em> type to <strong>allowedTypes</strong> is completely safe — it's in your diff and selective push handles it automatically.</p>
<blockquote>
<p><strong>One possible approach:</strong> A pre-push step that reads all <strong>allowedTypes</strong> / <strong>restrictedTypes</strong> arrays and verifies every key they name still exists in the codebase could act as an early warning. Whether that's worth building depends on how often your model changes and how much a broken shared environment costs your team.</p>
</blockquote>
<hr />
<h2>Case 5 — Key rename: unavoidable sometimes, never trivial</h2>
<blockquote>
<p>⚠️ <strong>Design your keys well upfront and you likely won't face this. But if you do, know exactly what happens.</strong></p>
</blockquote>
<p>The <strong>key</strong> of a content type, contract, or property is its permanent identity on the CMS instance. There is no rename operation — what actually happens is a <strong>delete of the old + create of the new</strong>. The CMS treats them as two completely different entities.</p>
<p>Consequences:</p>
<ul class="tight">
<li>
<p>All content items created under the old key are orphaned</p>
</li>
<li>
<p>Every type that names the old key — in <strong>allowedTypes</strong>, <strong>restrictedTypes</strong>, typed <strong>contentType</strong> properties, <strong>contracts</strong> arrays — is now broken</p>
</li>
<li>
<p>Git diff shows only the file where the key string changed, nothing about files that reference it elsewhere</p>
</li>
</ul>
<p>📖 <a href="https://docs.developers.optimizely.com/content-management-system/v1.0.0-CMS-SaaS/docs/manage-content-types-using-the-rest-api">Manage content types — key field</a></p>
<pre class="code-block"><code class="language-json">// BEFORE: 'blogPage' is the live key
{ "key": "blogPage", "baseType": "_page" }
{ "allowedTypes": ["articlePage", "blogPage"] } // another type, referencing it
// AFTER: key renamed to 'blogPostPage'
{ "key": "blogPostPage", "baseType": "_page" } // BlogPage.tsx — in your diff
{ "allowedTypes": ["articlePage", "blogPage"] } // LandingPage.tsx — NOT in your diff, now broken</code></pre>
<p><strong>The realistic minimum when a rename is unavoidable:</strong></p>
<ol class="tight">
<li>
<p>Search the full codebase for the old key string (<strong>grep -r "blogPage" src/</strong> is the starting point)</p>
</li>
<li>
<p>Update every file that references it in the same branch</p>
</li>
<li>
<p>Run a <strong>coordinated full push</strong> — not a selective push</p>
</li>
<li>
<p>Plan content migration separately — existing content under the old key is not auto-migrated</p>
</li>
</ol>
<p><strong>displayName</strong> is free to rename at any time. <strong>key</strong> is permanent the moment it lands on an instance.</p>
<h3>One direction worth exploring: detect the rename at diff time</h3>
<p>Git has the information you need — you can pull the <em>old</em> version of any changed file and compare key values:</p>
<pre class="code-block"><code class="language-bash"># Get the old content of a file as it was on the base branch
git show origin/main:src/content-model/pages/BlogPage.tsx</code></pre>
<p>For each modified content-type file: extract the old <strong>key</strong> and the new <strong>key</strong>. If they differ, search the codebase for the old key and surface every file that still references it. That turns a silent, easy-to-miss breakage into a loud early warning. You still need the coordinated full push — but at least you know why before you push, rather than after.</p>
<p>We haven't battle-tested this in a complex repo. It's a direction that seems worth exploring, not a recommendation.</p>
<h4>The Safe Alternative: The Editorial Deprecation Pattern</h4>
<p>Instead of performing a destructive key rename, the industry-standard best practice is to <strong>deprecate</strong> the old field and introduce the new one alongside it. While CMS SaaS doesn't have a native "deprecated" JSON flag in the schema, you can enforce this through an <strong>editorial convention</strong> in your code:</p>
<ol class="tight">
<li>
<p><strong>Remove constraints:</strong> Set <strong>"required": false</strong> on the old field so editors are never blocked.</p>
</li>
<li>
<p><strong>Warn editors in the UI:</strong> Update its <strong>displayName</strong> to include <strong>(Obsolete)</strong> and use the <strong>description</strong> to point to the new property.</p>
</li>
<li>
<p><strong>Warn developers in the IDE:</strong> Add a JSDoc <strong>@deprecated</strong> comment to the TypeScript interface.</p>
</li>
</ol>
<pre class="code-block"><code class="language-javascript">// src/content-model/components/TeaserBlock.tsx
export interface TeaserBlockType extends ContentType {
heading: string;
/**
* @deprecated Use 'heroImage' instead. This field is scheduled for removal in Q4.
*/
imageLink?: string; // Suffix with ? to make it optional in TS
}
export const TeaserBlockSchema = {
key: 'teaserBlock',
baseType: '_component',
displayName: 'Teaser Block',
properties: {
heading: { type: 'string', displayName: 'Heading', required: true },
imageLink: {
type: 'string',
displayName: 'Image Link (Obsolete)',
description: 'Deprecated. Use the Hero Image property instead.',
required: false, // Must be optional to prevent editor lock-out
},
},
};</code></pre>
<p>This keeps the old schema active, preserves historical data on production, and gives both developers and editors loud warnings. Only after several release cycles (when audit logs confirm no content remains in the old field) do you coordinate with your team to delete the key.</p>
<blockquote>
<p><strong>Our suggested approach:</strong> Treat renames as deliberate, planned events requiring a full codebase audit before any push. The git-blob detection above is a reasonable middle ground — cheap to build, fails loudly. But no script makes a key rename safe on its own.</p>
</blockquote>
<hr />
<h2>The Repo Structure That Makes All of This More Tractable</h2>
<p>Every detection approach above — scanning for contract references, extracting group keys, comparing old and new key values — relies on being able to tell <em>what kind of thing</em> a changed file is from where it lives. In a flat folder where contracts, pages, blocks, and templates all coexist, that falls apart immediately.</p>
<p>A deliberate folder structure is what makes any of this tractable. It won't solve the dependency problem on its own, but it gives your scripts — and your reviewers — something to reason from.</p>
<pre class="code-block"><code>src/
└── content-model/ # Everything the CLI pushes as schema
├── contracts/ # Shared interfaces — Case 1 blast radius
│ ├── Categorizable.ts # category + tags fields shared across types
│ └── IHeroImage.ts # heroImage + heroAlt fields
├── pages/ # _page base type
│ ├── ArticlePage.tsx
│ ├── LandingPage.tsx
│ └── BlogPage.tsx
├── components/ # _component base type (blocks AND elements)
│ ├── TeaserBlock.tsx
│ ├── HeroBlock.tsx
│ ├── HeadingElement.tsx # an "element" is just a component with restricted config
│ └── ParagraphElement.tsx
├── experiences/ # _experience base type
│ └── BlankExperience.tsx
└── sections/ # _section base type
└── BlankSection.tsx
src/
└── templates/ # Display templates — decoupled, own push lane
├── ArticlePage.style.ts # Wide / Narrow display variants for ArticlePage
├── TeaserBlock.style.ts # Card / Banner display variants for TeaserBlock
└── section-grid.style.ts # 1-col / 2-col / 3-col section layout options</code></pre>
<p>A note on <strong>elements</strong>: in the JavaScript SDK, an element is not a separate base type — it's a <strong>_component</strong> with restricted configuration (it's meant to be used as a Visual Builder building block rather than a standalone block). Because it's still a component, it lives in the same folder and behaves identically for push-dependency purposes. Group by base type, not by editorial role.</p>
<p><strong>Property groups</strong> don't get their own files either — they live in <strong>optimizely.config.mjs</strong> as the propertyGroups array. If your config grows large you can split it into an imported module, but the source of truth stays the config file.</p>
<h3>What templates actually are</h3>
<p>A template file registers display variations that editors can apply to content nodes in Visual Builder. They are pure style/visual configuration — they carry no content schema. This is why they can be pushed on their own lane without any dependency scanning.</p>
<p>A display template applies to a content type (or base type, or structural node) and exposes editor-selectable settings:</p>
<pre class="code-block"><code class="language-typescript">// src/templates/TeaserBlock.style.ts
// POST https://api.cms.optimizely.com/v1/displaytemplates
export const teaserBlockCardStyle = {
key: 'TeaserBlockCard',
displayName: 'Card',
contentType: 'teaserBlock', // applies to this specific content type
settings: {
ImagePosition: {
displayName: 'Image Position',
editor: 'select',
choices: {
Left: { displayName: 'Left', sortOrder: 1 },
Right: { displayName: 'Right', sortOrder: 2 },
Top: { displayName: 'Top', sortOrder: 3 }
}
}
}
};</code></pre>
<pre class="code-block"><code class="language-typescript">// src/templates/section-grid.style.ts
// A structural node template — applies to all sections
export const sectionGridStyle = {
key: 'SectionGrid',
displayName: 'Grid',
nodeType: 'section', // applies to all section nodes
settings: {
Columns: {
displayName: 'Columns',
editor: 'select',
choices: {
One: { displayName: '1 column', sortOrder: 1 },
Two: { displayName: '2 columns', sortOrder: 2 },
Three: { displayName: '3 columns', sortOrder: 3 }
}
}
}
};</code></pre>
<p>📖 <a href="https://docs.developers.optimizely.com/content-management-system/v1.0.0-CMS-SaaS/docs/configure-visual-builder">Configure Visual Builder</a> · <a href="https://docs.developers.optimizely.com/content-management-system/v1.0.0-CMS-SaaS/docs/work-with-styles">Manage styles</a></p>
<h3>The folder pays off in the script</h3>
<p>With this structure, a script can classify a changed file from its path alone:</p>
<ul class="tight">
<li>
<p>A file under <strong>content-model/contracts/</strong> → run the Case 1 scan</p>
</li>
<li>
<p>A file under <strong>content-model/pages/</strong> or <strong>content-model/components/</strong> → run the Case 3 scan</p>
</li>
<li>
<p><strong>optimizely.config.mjs</strong> changed → run the Case 2 check</p>
</li>
<li>
<p>A file under <strong>templates/</strong> → push on the templates lane, no schema scan needed</p>
</li>
</ul>
<p>It also opens the door to something more responsive: a file watcher during development that flags dependency-affecting changes the moment you save, before you ever run a push. We haven't built that — it's a direction the structure makes possible.</p>
<p>The honest caveat: no folder convention survives a team that doesn't follow it. The structure only works if it's agreed, documented, and enforced.</p>
<hr />
<h2>Shifting Our Mindset: Content Modeling as Schema Migration</h2>
<p>When you build on a headless, code-first content platform, your content type files are not just React rendering files. They represent your <strong>live database schema, your API contract, and your editorial UI layout all at once.</strong></p>
<p>In traditional software engineering, we treat database schemas with extreme discipline. You would never let a CI/CD build run a migration that drops database columns containing live customer data. You write versioned migrations, test them locally, and deploy them sequentially.</p>
<p>Content modeling in CMS SaaS requires the exact same engineering discipline.</p>
<p>This realization completely changes how we govern our code-first pipelines and why selective pushes exist:</p>
<ol class="tight">
<li>
<p><strong>Selective push is your local iteration tool.</strong> It is how developers move quickly on a shared sandbox without overwriting other unmerged work.</p>
</li>
<li>
<p><strong>The script is your diagnostic blueprint.</strong> When a build fails or conflicts occur, the branch-diff script is what you run to instantly map out the exact footprint of your changes and see which contracts or components are dragging dependents in.</p>
</li>
<li>
<p><strong>CI/CD is your schema safety gate.</strong> It must run strictly, never forcing, and failing loudly if anything is out of sync.</p>
</li>
</ol>
<p>Let’s look at how to structure your CI/CD pipeline to act as this hard firewall.</p>
<hr />
<h2>CI/CD Guardrails: The "Fail Loudly, Never Force" Principle</h2>
<p>In lower environments (like individual developer sandboxes), selective pushes and the propose-review-push workflow provide rapid feedback loops. But as your code travels up to shared environments, the governance must tighten.</p>
<table style="border-collapse: collapse; border-width: 1px; border-style: solid;">
<tbody>
<tr>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p><strong>Environment</strong></p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p><strong>Purpose</strong></p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p><strong>Push Strategy</strong></p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p><strong>CLI Flags</strong></p>
</td>
</tr>
<tr>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p><strong>Local Sandbox</strong></p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p>Individual dev space</p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p>Scoped / Selective push</p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p>Normal</p>
</td>
</tr>
<tr>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p><strong>Shared QA / Stage</strong></p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p>Team integration & content entry</p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p>Scoped or Full Push</p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p><strong>Strictly no --force</strong></p>
</td>
</tr>
<tr>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p><strong>Production</strong></p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p>Live consumer experience</p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p>Authoritative Full Push</p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p><strong>Strictly no --force</strong></p>
</td>
</tr>
</tbody>
</table>
<h3>Enforcing the Safety Gate</h3>
<p>The <strong>@optimizely/cms-cli</strong> is designed to fail loudly. If there is a schema conflict — such as a missing implementing type for a modified contract, or an invalid group key reference — the command exits with a non-zero exit code (typically <strong>1</strong>).</p>
<p>Any standard CI/CD engine (GitHub Actions, GitLab CI, Azure DevOps) will intercept this non-zero exit code and immediately fail the build step.</p>
<p>By running your staging and production pipelines <strong>without the --force flag</strong>, you ensure that if a developer checked in a breaking change without coordination, the build halts before a single production schema is modified or live data is orphaned.</p>
<h3>Diagnostic Recovery Workflow</h3>
<p>When the build fails, the team doesn't have to guess what broke. A developer runs the <strong>push-branch-changes.mjs</strong> script locally comparing the release branch to the target base (e.g., <strong>origin/main</strong>):</p>
<pre class="code-block"><code class="language-bash">npm run cms:push:types release/q3 origin/main</code></pre>
<p>The script outputs the precise dependency tree of the changed files. The team can instantly pinpoint: <em>"Ah! Someone updated the contract, which dragged in ArticlePage. But ArticlePage on Stage has custom fields that are still locked in another draft. That's our conflict."</em></p>
<p>It turns a black-box build failure into an actionable, reviewable transaction map.</p>
<hr />
<h2>The Workflow: Propose, Review, Push</h2>
<p>The script below doesn't push for you automatically. It detects, proposes, and hands you a reviewable config. You decide whether to push it.</p>
<p>The loop:</p>
<ol class="tight">
<li>
<p>Run one command against your branch.</p>
</li>
<li>
<p>The script diffs your branch, classifies each changed file by its folder, and runs the relevant dependency scans for Cases 1–3.</p>
</li>
<li>
<p>It <strong>writes a temporary config</strong> listing the proposed push set — your changed files plus every dependent it found — and prints the list.</p>
</li>
<li>
<p>You review the list. Does it look right? Anything surprising, or anything missing you expected? For Cases 4–5 it flags what needs a human decision.</p>
</li>
<li>
<p>If you're satisfied, you run the push command it hands you.</p>
</li>
</ol>
<p>This isn't overhead instead of a solution. It's a gate that makes a scoped push reviewable before it lands on a shared instance — something a blind full push can't give you.</p>
<p>Two commands, split by concern:</p>
<pre class="code-block"><code class="language-json">// package.json
"scripts": {
"cms:push:templates": "npx @optimizely/cms-cli@latest push --config optimizely.config.templates.mjs",
"cms:push:types": "node push-branch-changes.mjs"
}</code></pre>
<p><strong>Templates lane —</strong> display templates and Visual Builder styles. Zero schema risk. No review needed.</p>
<p><strong>Types lane —</strong> content types and contracts together, via the propose-review-push script below.</p>
<hr />
<h2>One Rough Starting Point for the Script</h2>
<p>This extends the script from Part 1 to attempt dependency detection for Cases 1–3. We're sharing it as a concept, not a drop-in solution. It makes simplifying assumptions — consistent folder structure, filename-based detection, flat directory scanning — that won't hold in every project. Treat it as something to adapt, not something to copy.</p>
<p>Cases 4 and 5 (key renames and deletions) are not automatable in any reliable way. The script blocks on file deletions to at least surface the problem. Key value renames it cannot detect at all without the git-blob comparison described in Case 5.</p>
<p>📖 <a href="https://docs.developers.optimizely.com/content-management-system/v1.0.0-CMS-SaaS/docs">JavaScript SDK docs</a></p>
<pre class="code-block"><code class="language-javascript">// push-branch-changes.mjs — adapt to your folder structure
import { execSync } from 'child_process';
import fs from 'fs';
import path from 'path';
const baseBranch = process.argv[2] || 'origin/main';
const tempConfig = 'optimizely.config.temp.mjs';
// Match your actual folder structure. Note: elements live under components.
const PAGES_DIR = 'src/content-model/pages';
const COMPONENTS_DIR = 'src/content-model/components';
const CONTRACTS_DIR = 'src/content-model/contracts';
const ALL_TYPES_DIRS = [PAGES_DIR, COMPONENTS_DIR, CONTRACTS_DIR];
try {
console.log(`Diffing against ${baseBranch}...`);
const gitOutput = execSync(`git diff ${baseBranch} --name-only`, { encoding: 'utf8' });
const changedFiles = gitOutput
.split('\n').map(f => f.trim())
.filter(f => f.length > 0 && fs.existsSync(f));
if (changedFiles.length === 0) {
console.log('No changes. Nothing to push.');
process.exit(0);
}
// ── Block on deletions — requires human audit before any push
const deletedFiles = execSync(
`git diff ${baseBranch} --name-only --diff-filter=D`, { encoding: 'utf8' }
).split('\n').map(f => f.trim()).filter(Boolean);
const deletedTypes = deletedFiles.filter(f => ALL_TYPES_DIRS.some(d => f.startsWith(d)));
if (deletedTypes.length > 0) {
console.error('\n[BLOCKED] Deleted content type or contract files:');
deletedTypes.forEach(f => console.error(` - ${f}`));
console.error('\nAudit all referencing files before running a coordinated full push.\n');
process.exit(1);
}
const pushRegistry = new Set();
changedFiles
.filter(f => ALL_TYPES_DIRS.some(d => f.startsWith(d)))
.forEach(f => pushRegistry.add(f));
// All content-model files — used for scanning
const allTypeFiles = ALL_TYPES_DIRS.flatMap(dir =>
fs.existsSync(dir)
? fs.readdirSync(dir, { recursive: true })
.filter(f => f.endsWith('.tsx') || f.endsWith('.ts'))
.map(f => path.join(dir, f))
: []
);
// ── Case 1: Contract changes → scan for implementing types
const changedContracts = changedFiles.filter(f => f.startsWith(CONTRACTS_DIR));
if (changedContracts.length > 0) {
console.log('\n[Case 1] Contract changes — scanning for implementing types...');
const names = changedContracts.map(f => path.basename(f, path.extname(f)));
expandDependents(allTypeFiles, names, pushRegistry, 'implements contract');
}
// ── Case 2: Property group key changes → scan for referencing types
const changedConfig = changedFiles.find(f => f === 'optimizely.config.mjs');
if (changedConfig) {
const src = fs.readFileSync(changedConfig, 'utf8');
const groupKeys = [...src.matchAll(/key:\s*['"](\w[\w-]*)['"]\s*,\s*displayName/g)].map(m => m[1]);
if (groupKeys.length > 0) {
console.log(`\n[Case 2] Property group keys (${groupKeys.join(', ')}) — scanning referencing types...`);
expandDependents(allTypeFiles, groupKeys, pushRegistry, 'references group key');
}
}
// ── Case 3: Component/page changes → scan for types that embed them
const changedComponents = changedFiles.filter(f =>
f.startsWith(COMPONENTS_DIR) || f.startsWith(PAGES_DIR)
);
if (changedComponents.length > 0) {
const names = changedComponents.map(f => path.basename(f, path.extname(f)));
console.log('\n[Case 3] Component/page changes — scanning for embedding types...');
expandDependents(allTypeFiles, names, pushRegistry, 'embeds as typed property');
}
const finalPushList = Array.from(pushRegistry);
if (finalPushList.length === 0) {
console.log('No pushable schema changes found.');
process.exit(0);
}
// ── Propose: write the temp config and print it for review
console.log(`\nProposed push set (${finalPushList.length} files) — review before confirming:`);
finalPushList.forEach(f => console.log(` - ${f}`));
const filePaths = finalPushList.map(f => `'./${f}'`).join(',\n ');
fs.writeFileSync(tempConfig,
`import { buildConfig } from '@optimizely/cms-sdk';
export default buildConfig({ components: [\n ${filePaths}\n ] });
`, 'utf8');
console.log(`\nWrote ${tempConfig}. Review it, then push with:`);
console.log(` npx @optimizely/cms-cli@latest push --config ${tempConfig}\n`);
// The script stops here and hands you the command rather than pushing automatically.
// If you're confident in the detection for your project, you can execSync the push instead.
} catch (err) {
console.error('Failed:', err.message);
if (fs.existsSync(tempConfig)) fs.unlinkSync(tempConfig);
process.exit(1);
}
function expandDependents(allFiles, names, registry, reason) {
for (const filePath of allFiles) {
if (registry.has(filePath)) continue;
const source = fs.readFileSync(filePath, 'utf8');
const matched = names.find(name => source.includes(name));
if (matched) {
console.log(` -> Including ${filePath} (${reason}: '${matched}')`);
registry.add(filePath);
}
}
}</code></pre>
<p><strong>Known limitations worth being honest about:</strong> String scanning produces false positives in loosely structured projects — a rendering import looks identical to a schema embed reference. The property group regex is fragile if your config format differs. Key renames inside a still-present file are invisible to this script entirely. These aren't edge cases to dismiss — they're reasons to test this against your actual project before leaning on it.</p>
<hr />
<h2>Forward Looking: Maturing to a Shared Package</h2>
<p>For larger enterprise projects or teams handling multiple concurrent front-end applications, a final maturity step is to <strong>extract the content model layer into its own npm package</strong> (such as <strong>@yourorg/content-model</strong>).</p>
<p>This moves your schema definitions into their own independent repository with strict versioning and ownership:</p>
<ul class="tight">
<li>
<p><strong>Strict Review Gates:</strong> The package can have its own <strong>package.json</strong>, its own CI validation, and its own <strong>CODEOWNERS</strong> file — meaning no developer can alter a contract or change a schema key without explicit approval from a content architect.</p>
</li>
<li>
<p><strong>Semantic Versioning:</strong> Schema changes are published as versioned releases. A breaking key rename is mapped to a Major version bump, acting as a clear, standard signal to every consuming front-end application.</p>
</li>
<li>
<p><strong>Isolate the Pipeline:</strong> The CI/CD push logic lives with the package that defines the models. The client applications simply consume the published TypeScript interfaces.</p>
</li>
</ul>
<p>While a separate package adds publishing overhead that might be overkill for smaller single-team projects, it represents the logical north star for teams managing Optimizely CMS SaaS at true scale.</p>
<hr />
<h2>Design-Time Guidelines</h2>
<p>The structure and script address what happens. These habits reduce how many cases happen in the first place.</p>
<ul class="tight">
<li>
<p><strong>Treat contracts like a public API.</strong> Get their shape right before multiple types implement them. Every field you add later drags every implementer into the same push. Small, focused contracts are cheaper to change than broad ones.</p>
</li>
<li>
<p><strong>Freeze keys once a type lands on any shared instance.</strong> Key rename = delete + create. Change <strong>displayName</strong> freely — it's cosmetic. Treat <strong>key</strong> as permanent from day one.</p>
</li>
<li>
<p><strong>Prefer additive changes.</strong> Adding a property is safe and localised. Deprecate and add rather than rename or delete.</p>
</li>
<li>
<p><strong>Separate your content-model layer from your app code and templates.</strong> The folder structure is what makes any detection approach tractable.</p>
</li>
<li>
<p><strong>Push in dependency order on fresh environments.</strong> Property groups first, then contracts, then types that implement them.</p>
</li>
<li>
<p><strong>Route true breaking changes through a full push.</strong> Key renames, deletions, dropping a contract — these are coordination events. Merge, let CI/CD do the authoritative full push, plan content migration separately.</p>
</li>
</ul>
<hr />
<h2>Summary</h2>
<table style="border-collapse: collapse; border-width: 1px; border-style: solid; width: 100%;">
<tbody>
<tr>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top; background-color: rgb(206, 212, 217);">
<p><strong>What changed</strong></p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top; background-color: rgb(206, 212, 217);">
<p><strong>Dependency created</strong></p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top; background-color: rgb(206, 212, 217);">
<p><strong>Direction to explore</strong></p>
</td>
</tr>
<tr>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p>Field added to a <strong>contract</strong></p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p>All implementing types (transitive)</p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p>Scan by contract folder + name — reliability varies</p>
</td>
</tr>
<tr>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p><strong>Property group</strong> key changed</p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p>All types using that group key</p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p>Diff config + scan, or manual review at PR time</p>
</td>
</tr>
<tr>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p><strong>Component</strong> schema changed</p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p>All types embedding it as a typed property</p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p>Scan by component folder + name</p>
</td>
</tr>
<tr>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p>Type added to <strong>allowedTypes</strong></p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p>None — stays in your diff</p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p>No extra action needed</p>
</td>
</tr>
<tr>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p>Referenced type key <strong>renamed or deleted</strong></p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p>All types naming it anywhere</p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p>Git-blob compare to detect + coordinated full push</p>
</td>
</tr>
</tbody>
</table>
<p> </p>
<table style="border-collapse: collapse; border-width: 1px; border-style: solid; width: 100%;">
<tbody>
<tr style="height: 47.6px;">
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top; height: 47.6px; background-color: rgb(206, 212, 217);">
<p><strong>Environment</strong></p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top; height: 47.6px; background-color: rgb(206, 212, 217);">
<p><strong>Templates</strong></p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top; height: 47.6px; background-color: rgb(206, 212, 217);">
<p><strong>Content types + contracts</strong></p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top; height: 47.6px; background-color: rgb(206, 212, 217);">
<p><strong>Key renames</strong></p>
</td>
</tr>
<tr style="height: 47.6px;">
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top; height: 47.6px;">
<p><strong>Developer instances</strong></p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top; height: 47.6px;">
<p>Full push of template config</p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top; height: 47.6px;">
<p>Propose-review-push (adapted to your project)</p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top; height: 47.6px;">
<p>Never selective</p>
</td>
</tr>
<tr style="height: 47.6px;">
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top; height: 47.6px;">
<p><strong>Shared QA / Staging</strong></p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top; height: 47.6px;">
<p>Full push on merge</p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top; height: 47.6px;">
<p>Full push on merge</p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top; height: 47.6px;">
<p>Full push after team coordination</p>
</td>
</tr>
<tr style="height: 67.2px;">
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top; height: 67.2px;">
<p><strong>Production</strong></p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top; height: 67.2px;">
<p>CI/CD on release</p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top; height: 67.2px;">
<p>CI/CD on release</p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top; height: 67.2px;">
<p>Coordinated release + content migration</p>
</td>
</tr>
</tbody>
</table>
<hr />
<h2>The Point</h2>
<p>Part 1 gave you selective push — it works, and it's still the right approach for the vast majority of day-to-day content type changes.</p>
<p>This part maps the cases where it gets more complex: when a single-file change reaches further than the diff suggests. The five cases are real — the CMS validates them this way and you will hit them. The folder structure and propose-review-push workflow are directions we think are worth exploring, not a proven system.</p>
<p>We're publishing this partly because the answer isn't fully settled. If you've solved any of these more cleanly — or found that some of this doesn't hold up in practice — that's exactly the kind of feedback this series is for.</p>
<p>Know the cases. Structure the repo. Let the workflow propose, and you review.</p>
<hr />
<p><em>Have you hit any of these dependency cases on a project? Particularly curious whether the folder-structure approach holds up in practice, and whether anyone has a cleaner answer for the key-rename detection. Comments open below.</em></p>2026-07-25T12:23:05.0000000ZBlog postParallel Development in Optimizely CMS SaaS: A Smarter Way to Register Components<p><strong>📌 A note before you read:</strong> The approach described in this article is not a replacement for Optimizely’s recommended out-of-the-box component registration pattern — which is clean, explicit, and exactly right for most projects. This is written for teams of <strong>4 or more developers</strong> working on <strong>parallel feature branches</strong> who are finding that a shared registry file is becoming a source of repeated, low-value merge conflicts. If that’s not your situation yet, file this away for when it is.</p>
<hr />
<p>When Optimizely introduced code-first content modeling for CMS SaaS, they solved one of the biggest headaches in modern CMS development. Being able to define your content types in standard <strong>.tsx</strong> files and push them via the CLI is a massive developer experience win.</p>
<p>But modeling is only half the equation. On the frontend, you must map those content types to actual React components so the SDK can resolve and render them.</p>
<p>The standard approach uses a central registration file — typically in your Next.js layout or a dedicated registry file — where you manually import every single component and content type, registering them with <strong>initContentTypeRegistry</strong> and <strong>initReactComponentRegistry</strong>:</p>
<pre class="code-block"><code class="language-typescript">// The classic static registration (e.g., src/components/registry.ts)
import { initContentTypeRegistry } from '@optimizely/cms-sdk';
import { initReactComponentRegistry } from '@optimizely/cms-sdk/react/server';
import HeroBanner, { HeroBannerContentType } from './HeroBanner';
import ArticlePage, { ArticlePageContentType } from './ArticlePage';
import GridContainer, { GridContainerContentType } from './GridContainer';
export function registerComponents() {
initContentTypeRegistry([
HeroBannerContentType,
ArticlePageContentType,
GridContainerContentType,
]);
initReactComponentRegistry({
resolver: {
HeroBanner,
ArticlePage,
GridContainer,
},
});
}</code></pre>
<p>This explicit registration is an excellent default design. It's clean, type-safe, and self-documenting.</p>
<p>But as your engineering team grows from one developer to five, ten, or twenty working in parallel, this central registry file starts to feel a bit crowded.</p>
<p>Let's talk about the friction this creates — and how a small shift in thinking can clean up your git history forever.</p>
<hr />
<h2>The Tragedy of the Common Registry File</h2>
<p>Imagine a typical day on an enterprise development team.</p>
<ul class="tight">
<li>
<p><strong>Developer A</strong> is on a feature branch building a new <strong>PromoCard</strong> component.</p>
</li>
<li>
<p><strong>Developer B</strong> is on a separate branch creating an <strong>AuthorBio</strong> content type.</p>
</li>
<li>
<p><strong>Developer C</strong> is refactoring the <strong>NavigationMenu</strong>.</p>
</li>
</ul>
<p>Each developer creates their standalone component file. But to make it work in their respective sandbox environments, they <em>all</em> have to touch the exact same central file — <strong>src/components/registry.ts</strong> — to import and register their work.</p>
<p>Everything works beautifully in isolation. The local tests pass, and the PRs are opened.</p>
<p>But when the time comes to merge these branches back into <strong>main</strong>, Git grinds to a halt. There's a merge conflict in <strong>registry.ts</strong>. Because everyone modified the exact same import list on the exact same lines, the automated merge fails.</p>
<p>Dealing with merge conflicts on actual code logic is a normal part of engineering. Dealing with merge conflicts on a <em>list of import statements</em> is just tax. It slows down your CI/CD pipelines, frustrates developers, and adds zero business value.</p>
<hr />
<h2>The Mind Shift: Static Imports vs. Runtime Discovery</h2>
<p>The default behavior of manually importing components in a static file is excellent for small projects or stable schemas. It provides absolute certainty about what is being loaded — Optimizely's design here is intentional and solid.</p>
<p>But as you scale parallel development, the question changes: <em>"Do we really need to declare what files exist when our file system already knows?"</em></p>
<p>This is the mental model shift: <strong>move from manual, static registration to automated, runtime discovery.</strong></p>
<p>If a developer places a valid component — with its matching <strong>contentType</strong> definition — inside the <strong>src/components</strong> folder, the project should automatically detect and register it. Your folder structure is the source of truth; your registry file should simply reflect that truth dynamically at build time.</p>
<p>By generating this registry file automatically, we preserve all the power, safety, and type-safety of Optimizely's SDK while eliminating manual list maintenance — and the inevitable merge conflicts that come with it — entirely.</p>
<p>The question for your team to consider: is the overhead of manually maintaining the registry file appropriate for the size and pace of your team? For a solo developer or a two-person squad, the static approach is perfect. For five or more developers running parallel feature tracks, automation becomes the right call.</p>
<hr />
<h2>Implementing Registry Generation</h2>
<p>Instead of writing complex dynamic imports that can sometimes complicate React server-side rendering or bundle splitting, the most robust approach is a lightweight pre-build <strong>codegen script</strong> that automatically compiles your <strong>registry.ts</strong> file right before your app starts or builds.</p>
<p>This is a well-established industry pattern that works perfectly with standard Next.js and React environments.</p>
<h3>1. The Registry Generator Script</h3>
<p>Create a native Node.js script in your project root: <strong>generate-registry.mjs</strong>. It recursively scans <strong>src/components</strong>, finds every component file, and writes a fully-resolved <strong>registry.ts</strong>.</p>
<pre class="code-block"><code class="language-javascript">// generate-registry.mjs
import fs from 'fs';
import path from 'path';
const COMPONENTS_DIR = './src/components';
const OUTPUT_FILE = './src/components/registry.ts';
function getComponentFiles(dir, filesList = []) {
if (!fs.existsSync(dir)) return filesList;
const items = fs.readdirSync(dir);
for (const item of items) {
const fullPath = path.join(dir, item);
const stat = fs.statSync(fullPath);
if (stat.isDirectory()) {
getComponentFiles(fullPath, filesList);
} else if ((item.endsWith('.tsx') || item.endsWith('.ts')) && !item.includes('registry')) {
// Expects each file to export a default component + a named ContentType
// e.g. export const HeroBannerContentType = contentType(...)
filesList.push(fullPath);
}
}
return filesList;
}
try {
console.log('[Optimizely Registry] Scanning components...');
const files = getComponentFiles(COMPONENTS_DIR);
const imports = [];
const contentTypes = [];
const resolvers = [];
files.forEach((file) => {
const relativePath = './' + path.relative(path.dirname(OUTPUT_FILE), file)
.replace(/\\/g, '/')
.replace(/\.tsx?$/, '');
const componentName = path.basename(file, path.extname(file));
const contentTypeConst = `${componentName}ContentType`;
imports.push(`import ${componentName}, { ${contentTypeConst} } from '${relativePath}';`);
contentTypes.push(` ${contentTypeConst}`);
resolvers.push(` ${componentName}`);
});
const output = `// ==========================================================================
// AUTO-GENERATED — do not edit manually. Changes will be overwritten.
// Run: node generate-registry.mjs | Source: generate-registry.mjs
// ==========================================================================
import { initContentTypeRegistry } from '@optimizely/cms-sdk';
import { initReactComponentRegistry } from '@optimizely/cms-sdk/react/server';
${imports.join('\n')}
export function registerComponents() {
initContentTypeRegistry([
${contentTypes.join(',\n')},
]);
initReactComponentRegistry({
resolver: {
${resolvers.join(',\n')},
},
});
}
`;
fs.writeFileSync(OUTPUT_FILE, output, 'utf8');
console.log(`[Optimizely Registry] Done — ${files.length} component(s) registered.`);
} catch (err) {
console.error('[Optimizely Registry] Generation failed:', err.message);
process.exit(1);
}</code></pre>
<h3>2. Wire It Into Your Lifecycle</h3>
<p>Hook the script into your <strong>package.json</strong> using npm's built-in <strong>pre</strong> hooks. It runs automatically before both <strong>dev</strong> and <strong>build</strong> — no manual step required.</p>
<pre class="code-block"><code class="language-json">"scripts": {
"predev": "node generate-registry.mjs",
"prebuild": "node generate-registry.mjs",
"dev": "next dev",
"build": "next build",
"start": "next start"
}</code></pre>
<p>Then add the generated file to <strong>.gitignore</strong>, since it is a build artifact:</p>
<pre class="code-block"><code class="language-bash"># .gitignore
src/components/registry.ts</code></pre>
<p>From this point on, no developer ever touches <strong>registry.ts</strong> again. It is generated fresh on every <strong>npm run dev</strong> and every CI/CD build run.</p>
<hr />
<h2>Why This Works on Local and CI/CD Alike</h2>
<p>Because the generator runs as part of the standard dev/build lifecycle, it scales flawlessly across all stages without any developer intervention.</p>
<table style="border-collapse: collapse; border-width: 1px; border-style: solid;">
<tbody>
<tr>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p><strong>Scenario</strong></p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p><strong>Static Registry</strong></p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p><strong>Generated Registry</strong></p>
</td>
</tr>
<tr>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p><strong>Local Sandbox</strong></p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p>Developers must manually add imports every time they create a component.</p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p>Creating a <strong>.tsx</strong> file and running <strong>npm run dev</strong> registers it automatically.</p>
</td>
</tr>
<tr>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p><strong>Feature Branch</strong></p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p>Every branch modifies the shared <strong>registry.ts</strong>, creating Git conflicts on merge.</p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p>Branches only contain the component file itself. <strong>registry.ts</strong> is Git-ignored. Merges are 100% clean.</p>
</td>
</tr>
<tr>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p><strong>CI/CD Pipeline</strong></p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p>Static imports are read as-is. A missed import causes a silent runtime failure.</p>
</td>
<td style="border-width: 1px; padding: 10px; border-style: solid; text-align: left; vertical-align: top;">
<p>The generator scans the actual workspace. If the file exists in the repo, it gets registered.</p>
</td>
</tr>
</tbody>
</table>
<hr />
<h2>Is This the Right Move for Your Team?</h2>
<p>Runtime registry generation isn't a universal answer — it's a tool for the right context. Here's how to think about it:</p>
<p><strong>Stick with the static registry if:</strong></p>
<ul class="tight">
<li>
<p>Your team is small (one to three developers)</p>
</li>
<li>
<p>Your schema is stable and rarely changes</p>
</li>
<li>
<p>You value absolute explicitness and prefer to control every import</p>
</li>
</ul>
<p><strong>Consider dynamic generation if:</strong></p>
<ul class="tight">
<li>
<p>You have four or more developers working on parallel feature branches</p>
</li>
<li>
<p>You're frequently hitting merge conflicts on a single registration file</p>
</li>
<li>
<p>You want your CI/CD pipeline to be self-healing rather than dependent on human memory</p>
</li>
</ul>
<p>Neither approach is wrong. The static model is exactly what Optimizely recommends out of the box — and for good reason. The generated model is a team-scale evolution of that same idea, where automation takes on the maintenance burden.</p>
<hr />
<h2>Wrapping Up</h2>
<p>Optimizely's SDK gives you a clean, type-safe, and explicit way to map content types to React components. That design is intentional and it's solid.</p>
<p>But as teams grow, automation should replace manual list-keeping. By shifting your mental model toward dynamic registry generation, you get the best of both worlds: the reliability and structure of Optimizely's component resolution, paired with a conflict-free, scalable parallel development workflow.</p>
<p>It's a simple script with a meaningful impact on your daily developer experience. Give it a try on your next feature sprint and let the filesystem do the organizing.</p>
<hr />
<p><em>Are you running into registry conflicts on your Optimizely CMS SaaS projects? Have you found other ways to automate the component wiring? Share what's working for your team in the comments — we'd love to hear it.</em></p>2026-07-21T05:42:00.0000000ZBlog postParallel Development in Optimizely CMS SaaS: A Smarter Way to Push Content Models<p>When Optimizely shipped the JavaScript SDK and CLI for CMS SaaS, they gave developers something pretty cool — a code-first workflow for content modeling. Define your content types in <strong>.tsx</strong> files, run <strong>npx @optimizely/cms-cli@latest push</strong>, and your content models land in the CMS instance via the REST API.</p>
<p>Clean. Fast. Developer-friendly.</p>
<p>But here's the thing about developer tools — the moment you hand them to a <em>team</em>, the dynamics shift. And that's not a flaw in the tooling. It's just what happens when multiple people start pushing content models to the same environment at the same time.</p>
<p>Let's talk about that.</p>
<hr />
<h2>The Reality of Parallel Development</h2>
<p>Picture this: you're on a feature branch, building out a <strong>HeroBanner</strong> component. Your teammate is on a separate branch, refining the <strong>ArticlePage</strong> schema. Both of you are pointing your CLI at the same non-production CMS instance.</p>
<p>You run <strong>push</strong>. The CLI reads your <strong>optimizely.config.mjs</strong>, scans the entire <strong>src/components/</strong> directory, and attempts to sync <em>everything</em> it finds — your changes, your teammate's changes, and every other content type definition sitting in the codebase.</p>
<p>Now, if your local branch doesn't have your teammate's latest work (because they haven't merged yet), the CLI sees a mismatch. It flags a conflict. You get an error.</p>
<p>This is actually <em>good behavior</em>. The CLI is protecting you from accidentally overwriting someone else's work. Optimizely built in a <strong>--force</strong> flag for exactly this reason — when you know what you're doing and want to push regardless, you can.</p>
<p>But here's where the mental model needs to shift.</p>
<hr />
<h2>The Force Flag Solves the Wrong Problem (For This Scenario)</h2>
<p>Let's be clear — the <strong>--force</strong> option is a legitimate and useful tool. It exists because there are real scenarios where you need to override what's on the remote instance. Schema migrations, breaking changes, cleanup operations — force is the right call.</p>
<p>But in a parallel development workflow, the question isn't <em>"how do I push harder?"</em> — it's <em>"why am I pushing things I didn't change?"</em></p>
<p>Think about it. If you only modified <strong>HeroBanner.tsx</strong>, why should the CLI even <em>look</em> at <strong>ArticlePage.tsx</strong>? Why should it care about 47 other component files that you never touched?</p>
<p>The problem isn't conflict resolution. The problem is <strong>scope</strong>.</p>
<hr />
<h2>A Different Way to Think About It</h2>
<p>Here's the mental shift: instead of treating the CLI push as a <em>full sync</em> operation, treat it as a <em>deployment of your changes</em>.</p>
<p>This is how we already think about code deployments. Your CI/CD pipeline doesn't redeploy every microservice when you change one. Your database migration tool doesn't re-run every migration from the beginning. You deploy <em>what changed</em>.</p>
<p>Content model pushes should work the same way.</p>
<p>The good news? The CLI already supports this. The <strong>optimizely.config.mjs</strong> file controls <em>which components the CLI processes</em>. If you narrow the <strong>components</strong> array to only the files you've changed, the CLI will only push those content types. No conflicts with your teammate's work. No force flags needed. No wasted API calls.</p>
<p>The trick is doing this <em>dynamically</em> — based on your actual Git branch changes.</p>
<hr />
<h2>Git as Your Scope Engine</h2>
<p>Your version control system already knows exactly what you changed. A simple <strong>git diff</strong> against your base branch gives you the precise list of modified <strong>.tsx</strong> files. From there, it's straightforward to generate a temporary config file, push only those components, and clean up.</p>
<p>Here's a Node.js script that handles the entire flow:</p>
<pre class="code-block"><code class="language-js">// push-branch-changes.mjs
import { execSync } from 'child_process';
import fs from 'fs';
import path from 'path';
const baseBranch = process.argv[2] || 'origin/main';
const tempConfig = 'optimizely.config.temp.mjs';
try {
console.log(`Checking changes against ${baseBranch}...`);
const gitOutput = execSync(
`git diff ${baseBranch} --name-only -- "src/components/**/*.tsx"`,
{ encoding: 'utf8' }
);
const changedFiles = gitOutput
.split('\n')
.map(f => f.trim())
.filter(f => f.length > 0 && fs.existsSync(f));
if (changedFiles.length === 0) {
console.log('No component changes on this branch. Nothing to push.');
process.exit(0);
}
console.log(`\nPushing ${changedFiles.length} changed component(s):`);
changedFiles.forEach(f => console.log(` - ${f}`));
// Generate a temporary config scoped to changed files only
const paths = changedFiles.map(f => `'./${f}'`).join(',\n ');
const config = `import { buildConfig } from '@optimizely/cms-sdk';
export default buildConfig({
components: [
${paths}
],
});
`;
fs.writeFileSync(path.resolve(tempConfig), config, 'utf8');
// Push using the scoped config
execSync(`npx @optimizely/cms-cli@latest push --config ${tempConfig}`, {
stdio: 'inherit',
});
// Cleanup
fs.unlinkSync(tempConfig);
console.log('Done. Only your branch changes were pushed.');
} catch (err) {
console.error('Push failed:', err.message);
if (fs.existsSync(tempConfig)) fs.unlinkSync(tempConfig);
process.exit(1);
}</code></pre>
<p>Wire it up in your <strong>package.json</strong>:</p>
<pre class="code-block"><code class="language-json">"scripts": {
"cms:push-branch": "node push-branch-changes.mjs"
}</code></pre>
<p>And run it:</p>
<pre class="code-block"><code class="language-bash"># Compare against origin/main (default)
npm run cms:push-branch
# Or compare against a different base
npm run cms:push-branch origin/develop</code></pre>
<p>That's it. The script diffs your branch, generates a scoped config, pushes only your changes, and cleans up after itself.</p>
<hr />
<h2>What This Actually Gets You</h2>
<p><strong>Speed.</strong> Instead of the CLI parsing and validating every content type in your project, it processes only the handful you touched. On larger codebases with dozens of content types, the difference is noticeable.</p>
<p><strong>Safety.</strong> You literally cannot overwrite a teammate's content type because the CLI never sees it. There's no conflict to resolve, no force flag to debate, no Slack message asking <em>"did someone just push over my changes?"</em></p>
<p><strong>Focus.</strong> Your push operation maps 1:1 to your pull request. What you changed in code is what gets pushed to the CMS. Nothing more, nothing less. That's easier to review, easier to debug, and easier to roll back.</p>
<hr />
<h2>Where This Fits in a Bigger Picture</h2>
<p>This approach pairs well with a structured environment strategy. Consider this setup:</p>
<table style="border-collapse: collapse; border-width: 1px; border-style: solid;">
<tbody>
<tr>
<td style="padding: 10px; text-align: left; vertical-align: top; border-width: 1px; border-style: solid;">
<p><strong>Environment</strong></p>
</td>
<td style="padding: 10px; text-align: left; vertical-align: top; border-width: 1px; border-style: solid;">
<p><strong>Who Pushes</strong></p>
</td>
<td style="padding: 10px; text-align: left; vertical-align: top; border-width: 1px; border-style: solid;">
<p><strong>How</strong></p>
</td>
</tr>
<tr>
<td style="padding: 10px; text-align: left; vertical-align: top; border-width: 1px; border-style: solid;">
<p>Developer instances</p>
</td>
<td style="padding: 10px; text-align: left; vertical-align: top; border-width: 1px; border-style: solid;">
<p>Individual devs</p>
</td>
<td style="padding: 10px; text-align: left; vertical-align: top; border-width: 1px; border-style: solid;">
<p>Branch-scoped push (this script)</p>
</td>
</tr>
<tr>
<td style="padding: 10px; text-align: left; vertical-align: top; border-width: 1px; border-style: solid;">
<p>Shared QA/Staging</p>
</td>
<td style="padding: 10px; text-align: left; vertical-align: top; border-width: 1px; border-style: solid;">
<p>CI/CD pipeline</p>
</td>
<td style="padding: 10px; text-align: left; vertical-align: top; border-width: 1px; border-style: solid;">
<p>Full push on merge to main</p>
</td>
</tr>
<tr>
<td style="padding: 10px; text-align: left; vertical-align: top; border-width: 1px; border-style: solid;">
<p>Production</p>
</td>
<td style="padding: 10px; text-align: left; vertical-align: top; border-width: 1px; border-style: solid;">
<p>CI/CD pipeline</p>
</td>
<td style="padding: 10px; text-align: left; vertical-align: top; border-width: 1px; border-style: solid;">
<p>Full push on release</p>
</td>
</tr>
</tbody>
</table>
<p>Developers get fast, isolated feedback loops on their own instances. The shared environments only receive content models that have been reviewed and merged. Production stays locked down behind your release process.</p>
<p>The Optimizely CLI's full push behavior is <em>exactly right</em> for CI/CD — you want a complete sync when deploying from a merged, canonical branch. The branch-scoped approach fills the gap for the development phase, where speed and isolation matter more than completeness.</p>
<hr />
<h2>Wrapping Up</h2>
<p>The Optimizely CMS SaaS CLI is a solid tool. The force option exists for a reason and handles real conflicts well. But parallel development introduces a different kind of challenge — not <em>"how do I resolve conflicts"</em> but <em>"how do I avoid creating them in the first place?"</em></p>
<p>By scoping your pushes to only the content types you've actually changed, you sidestep the problem entirely. Your Git branch becomes the source of truth for what gets pushed, and everyone on the team stays out of each other's way.</p>
<p>It's a small script with a big impact on your daily workflow. Give it a try on your next feature branch.</p>
<hr />
<p><em>Have you tried a similar approach or found other ways to streamline parallel development with Optimizely CMS SaaS? We'd love to hear what's working for your team.</em></p>2026-07-20T09:04:26.0000000ZBlog postThe Silent Success: When Your Optimizely SaaS CMS Config Push Succeeds with "0" Changes<p> </p>
<p>Picture this frustratingly common scenario in headless, code-first development with Optimizely SaaS CMS:</p>
<p>You’ve defined a brilliant new element, block, or page type in your React codebase. You trigger your local push command. The console works its magic, spinning up green indicators and a clean finish:</p>
<pre class="code-block"><code>📤 Pushing content types...
✓ Configuration file uploaded
✅ Push succeeded.</code></pre>
<p>But when you open the Optimizely CMS UI, navigate to <strong>Settings > Content Types</strong>, and look for your new type... there is absolutely, crushing nothingness.</p>
<p>You immediately jump into emergency triage mode. You double-check your <strong>.env</strong> keys. You check permissions. Everything is correct. So why did the CLI say "Success" while doing absolutely nothing?</p>
<p>This is the <strong>CLI Silent Empty Push</strong> — and to debug it, you have to work through a specific hierarchy of checks. Let's trace the journey from the most obvious suspects down to the real, silent culprit.</p>
<hr />
<h2>The "Everything Looks Correct" Checklist</h2>
<p>Before tear-downs and code reviews, developers usually start with the obvious infrastructure questions. Here is the checklist of things you likely already verified:</p>
<h3>🔍 Check 1: Client ID & Client Secret</h3>
<ul class="tight">
<li>
<p><strong>The Question:</strong> Are your credentials expired or invalid?</p>
</li>
<li>
<p><strong>How to verify:</strong> Run <strong>npx @optimizely/cms-cli@latest login</strong>. If the connection is broken, the CLI will throw an authentication error immediately. If it says "Authentication complete," your credentials are functional.</p>
</li>
</ul>
<h3>🔍 Check 2: API Permissions & Impersonation Scopes</h3>
<ul class="tight">
<li>
<p><strong>The Question:</strong> Does your API Key have the rights to actually write schemas?</p>
</li>
<li>
<p><strong>How to verify:</strong> Check <strong>Settings > API Keys</strong> in the CMS UI. Ensure the key is active and possesses write scopes. If your key lacks permissions, a push would trigger a stark <strong>403 Forbidden</strong> or <strong>401 Unauthorized</strong> error in your terminal.</p>
</li>
</ul>
<h3>🔍 Check 3: The Target Environment URL</h3>
<ul class="tight">
<li>
<p><strong>The Question:</strong> Are you accidentally pushing to the wrong sandbox or staging instance?</p>
</li>
<li>
<p><strong>How to verify:</strong> Inspect your <strong>OPTIMIZELY_CMS_API_URL</strong> environment variable. If you pushed to a different instance, the schemas would exist, just on the wrong server.</p>
</li>
</ul>
<hr />
<h3>If all of those are green, why is the CMS still empty?</h3>
<p>If credentials, permissions, and host URLs are completely correct, and the terminal prints a successful <strong>200 OK</strong>, you have officially bypassed standard configuration errors.</p>
<p>The issue isn't security or network-related. It is a silent, 12-character path resolution discrepancy.</p>
<hr />
<h2>What the Official Documentation Says</h2>
<p>The official Optimizely <a href="https://docs.developers.optimizely.com/content-management-system/v1.0.0-CMS-SaaS/docs/configure-javascript-sdk"><em>Configure JavaScript SDK</em></a> guide is explicit about where the configuration file should live. Step 4 reads:</p>
<blockquote>
<p>*"Create an <strong>optimizely.config.mjs</strong> file in the <strong>root of your project</strong>."</p>
</blockquote>
<p>The official project structure diagram reinforces this:</p>
<pre class="code-block"><code>.
├── src/
│ └── components/
├── .env
├── optimizely.config.mjs ← root level, explicitly
└── ...</code></pre>
<p>The documentation does not cover what happens when you move this file into a subdirectory — <strong>because it assumes you won't.</strong> Developers following natural project organisation instincts — a clean root, a monorepo structure, a dedicated <strong>config/</strong> folder for multiple environment files — deviate from this guidance without realising there is a hidden consequence.</p>
<p>The CLI works perfectly when the file is at the root. The moment it moves into a subdirectory, globs silently resolve against the wrong base path, and the push uploads nothing.</p>
<hr />
<h2>The Real Culprit: The Glob Resolution Trap</h2>
<p>In clean, modern JavaScript monorepos or well-structured project hierarchies, developers rarely leave configuration files floating in the root directory. To keep things tidy, we often organize configurations into subdirectories like <strong>.optimizely/</strong> or <strong>config/</strong>.</p>
<p>For instance, you might move your CMS configuration to:</p>
<pre><strong>config/optimizely.config.mjs</strong></pre>
<p>And inside that nested configuration file, you write your relative component search paths:</p>
<pre class="code-block"><code class="language-javascript">import { buildConfig } from '@optimizely/cms-sdk';
export default buildConfig({
components: ['./src/content-types/**/*.ts'],
});</code></pre>
<p>This is where the silent trap springs. Here is the golden rule of the Optimizely CMS CLI:</p>
<blockquote>
<p>⚠️ <strong>The CLI resolves glob patterns inside a configuration file relative to the location of the configuration file itself, not relative to the root directory where you ran the CLI command.</strong></p>
</blockquote>
<p>Because the configuration file lives inside the <strong>config/</strong> subdirectory, the CLI reads <strong>./src/content-types/...</strong> as relative to <strong>config/</strong>. It starts searching for your schemas here:</p>
<p><strong>config/src/content-types/**/*.ts</strong></p>
<p>That subdirectory path does not exist. The CLI scans the folder, matches <strong>0 files</strong>, and finds exactly <strong>0 schemas</strong> to process.</p>
<h3>Why did the CLI report success?</h3>
<p>The Optimizely CLI is highly permissive. If a glob pattern matches zero files, it does not throw an error or fail the build. It assumes you just have a clean configuration slate, packs up an empty schema payload, and uploads it.</p>
<p>The CMS API receives a valid, perfectly formed (but empty) configuration payload, updates nothing, and returns an <strong>HTTP 200 OK</strong>. The CLI reports <strong>Configuration file uploaded</strong> because the upload itself <em>did</em> succeed.</p>
<p>The result: a completely silent, completely successful push of nothing.</p>
<hr />
<h2>The Fix</h2>
<p>The simplest fix is to follow the official documentation — keep your configuration file at the <strong>project root</strong> where the CLI expects it:</p>
<pre class="code-block"><code class="language-bash"># ❌ Nested (globs resolve relative to config/ — finds nothing)
npx @optimizely/cms-cli config push config/optimizely.config.mjs
# ✅ Root level (globs resolve relative to root — finds your files)
npx @optimizely/cms-cli config push optimizely.config.mjs</code></pre>
<p>If you have a strong reason to keep the config file inside a subdirectory — such as a monorepo setup or managing multiple environment configurations — you can adjust the glob paths inside the config to step up one level:</p>
<pre class="code-block"><code class="language-javascript">import { buildConfig } from '@optimizely/cms-sdk';
export default buildConfig({
// ../ steps up from config/ back to the project root
components: ['../src/content-types/**/*.ts'],
});</code></pre>
<p>Both approaches work. The root-level approach aligns with official documentation and is the least error-prone for single-app projects. The <strong>../</strong> prefix approach is useful for monorepos or multi-environment setups where nesting is intentional.</p>
<hr />
<h2>Reusable Debugging Checklist for Teams</h2>
<p>Bookmark this order-of-operations checklist for the next time a developer on your team runs into missing content types after a successful-looking push:</p>
<ol class="tight">
<li>
<p><strong>CLI Authentication Test</strong> — Run <strong>npx @optimizely/cms-cli@latest login</strong> to rule out expired credentials.</p>
</li>
<li>
<p><strong>API Key Scope Verification</strong> — Confirm your key has write access under <strong>Settings > API Keys</strong> in the CMS.</p>
</li>
<li>
<p><strong>Environment URL Check</strong> — Verify <strong>OPTIMIZELY_CMS_API_URL</strong> points to the instance you are currently viewing.</p>
</li>
<li>
<p><strong>Config File Location Audit</strong> — Is your <strong>optimizely.config.mjs</strong> (or any dynamically generated config) in the project root? If it is nested in a subdirectory, check whether the glob paths inside use <strong>../</strong> to compensate.</p>
</li>
<li>
<p><strong>Glob Match Validation</strong> — Test whether your glob patterns actually match any files before pushing:</p>
<pre class="code-block"><code class="language-typescript">import { globSync } from 'fast-glob';
const matched = globSync('./src/content-types/**/*.ts');
if (matched.length === 0) {
console.error('❌ Zero files matched. Config push will be empty.');
}</code></pre>
</li>
<li>
<p><strong>Visual Builder Composition</strong> — If your type appears in <strong>Settings > Content Types</strong> but not in the Visual Builder editor, go to that type's <strong>Settings</strong> tab and enable <strong>"Available for composition in Visual Builder"</strong>.</p>
</li>
</ol>
<hr />
<h2>Key Takeaway</h2>
<p>The Optimizely developer documentation is clear: <strong>optimizely.config.mjs</strong> belongs at the root of your project. When it lives there, everything works exactly as expected. When it moves — even for completely legitimate reasons — the CLI's glob resolution silently breaks, the push uploads an empty payload, and the CMS returns a perfectly polite <strong>200 OK</strong>.</p>
<p>The fix is simple. The behaviour, however, is not documented — which is precisely what makes it one of the most confusing silent failures in a SaaS CMS headless setup.</p>
<p>One line change. Types appear instantly.</p>
<hr />
<p><em>Have you run into other silent failure modes when working with Optimizely SaaS CMS content type workflows? Share your experience in the comments — this kind of institutional knowledge keeps teams shipping faster.</em></p>2026-07-13T07:32:17.0000000ZBlog postArchitecting an Enterprise-Grade Development Pipeline in Optimizely SaaS CMS<p>Most enterprise teams show up to Optimizely SaaS CMS with a clear roadmap for their release pipeline: DEV → QA → Stage → Prod. Four logical environments to manage active coding, quality assurance, business sign-off, and live operations.</p>
<p>When setting up your initial cloud-native topology, the question immediately arises: how do we align this 4-stage pipeline with our SaaS CMS instances in a way that is automated, secure, and team-safe?</p>
<p>This is a practical guide for every dev lead, architect, and project manager looking to design a high-velocity, team-safe development workflow. We've mapped out the key architectural strategies, branching patterns, and deployment automation tactics to make your Optimizely SaaS CMS pipeline production-ready.</p>
<hr />
<h2>First, Let's Talk About What "Separate Applications" Can and Can't Do</h2>
<p>Before we dive into environment mapping, it's critical to understand how Optimizely SaaS CMS handles resource isolation: <strong>applications and environments are not the same thing.</strong></p>
<p>Within a single CMS SaaS instance, you can create multiple <strong>Applications</strong> — each with its own:</p>
<ul class="tight">
<li>
<p>Content tree and start page hierarchy</p>
</li>
<li>
<p>Preview URLs and hostname configuration</p>
</li>
<li>
<p>Routing and application root settings</p>
</li>
</ul>
<p>This is incredibly powerful for multi-site and multi-brand strategies. But here is the architectural boundary: <strong>content types are scoped to the instance, not the application.</strong> When a developer pushes a new content type or modifies an existing schema, that change is immediately live across every application on that instance. There is no branching, draft mode, or per-application isolation for schemas.</p>
<p>Because schemas are instance-wide, a shared development or testing instance requires a deliberate promotion strategy to ensure that active development doesn't disrupt running QA or staging cycles.</p>
<hr />
<h2>Analyzing the Topologies: Pros and Cons of Environment Sharing</h2>
<p>If your initial setup is configured with three physical SaaS instances, achieving a 4-stage pipeline requires pairing two of your logical phases onto a single instance. There are three primary ways to design this topology, each with distinct architectural consequences.</p>
<hr />
<h3>Topology 1: Shared DEV & QA (The Schema Bottleneck Pattern)</h3>
<p><strong>Overall Assessment: Not recommended for parallel development teams</strong></p>
<p>In this pattern, the first instance is shared by developers and QA testers, while Staging and Production remain fully isolated.</p>
<ul class="tight">
<li>
<p><strong>The Problem:</strong> Developers iterate constantly. Every new feature requires adding content types, modifying properties, or updating validation rules. In a shared setup, these schema changes land on the instance immediately.</p>
</li>
<li>
<p><strong>The Impact on QA:</strong> If a developer pushes an unverified or breaking schema change mid-sprint, it can instantly destabilize the testing environment, blocking QA automation runs and invalidating manual test cycles.</p>
</li>
<li>
<p><strong>Verdict:</strong> While workable for small, highly coordinated teams (1-2 developers), this pattern quickly becomes a bottleneck for larger teams working on parallel streams.</p>
</li>
</ul>
<hr />
<h3>Topology 2: DEV | Shared QA & Stage (The Recommended Pattern)</h3>
<p><strong>Overall Assessment: The gold standard for velocity and stability</strong></p>
<p>This pattern keeps your DEV environment fully isolated, while QA testing and User Acceptance Testing (UAT/Staging) share the middle instance.</p>
<ul class="tight">
<li>
<p><strong>Why it works:</strong> Developers have complete freedom to experiment, iterate, and break things on the DEV instance. Schemas are promoted to the QA+Stage instance only through a controlled, automated deployment gate.</p>
</li>
<li>
<p><strong>Managing the Share:</strong> Because QA and UAT/Staging are typically <strong>sequential, not simultaneous</strong>, they rarely require different schema versions at the same time. You complete functional QA, sign off on the release branch, and then hand over to business stakeholders for UAT on the same schema.</p>
</li>
<li>
<p><strong>How Separate Applications Help:</strong> By creating two separate <strong>Applications</strong> within this single instance, you cleanly isolate your content and preview layers:</p>
<ul class="tight">
<li>
<p><strong>QA Application:</strong> Points to your QA frontend deployment, using QA-specific content and automated test trees.</p>
</li>
<li>
<p><strong>UAT Application:</strong> Points to your Staging/UAT frontend deployment, showcasing pristine demo content for business stakeholders.</p>
</li>
</ul>
</li>
<li>
<p><strong>Verdict:</strong> This is the most robust topology for a 3-instance setup. It completely protects developer velocity and ensures production-level safety.</p>
</li>
</ul>
<hr />
<h3>Topology 3: DEV | QA | Shared Stage & Production (The High-Risk Pattern)</h3>
<p><strong>Overall Assessment: Avoid entirely</strong></p>
<p>In this pattern, DEV and QA are fully isolated, but business sign-off (Staging/UAT) happens on the production instance.</p>
<ul class="tight">
<li>
<p><strong>The Danger:</strong> Even with separate CMS applications isolating your live content tree from your draft UAT tree, <strong>schemas are still instance-wide</strong>.</p>
</li>
<li>
<p><strong>The Impact:</strong> Any content type modification or configuration change made during UAT is immediately live on production. A single configuration oversight during a stakeholder review session can trigger an immediate production incident.</p>
</li>
<li>
<p><strong>Verdict:</strong> Production stability is non-negotiable. This topology should never be used.</p>
</li>
</ul>
<hr />
<h2>The Pipeline Comparison Matrix</h2>
<table>
<tbody>
<tr>
<td style="border-style: solid; border-width: 1px;">
<p>Pipeline Strategy</p>
</td>
<td style="border-style: solid; border-width: 1px;">
<p>DEV+QA Shared / Stage / Prod</p>
</td>
<td style="border-style: solid; border-width: 1px;">
<p>DEV / QA+Stage Shared / Prod (Recommended)</p>
</td>
<td style="border-style: solid; border-width: 1px;">
<p>DEV / QA / Stage+Prod Shared</p>
</td>
</tr>
<tr>
<td style="border-style: solid; border-width: 1px;">
<p>Developer Freedom</p>
</td>
<td style="border-style: solid; border-width: 1px;">
<p>❌ Constrained</p>
</td>
<td style="border-style: solid; border-width: 1px;">
<p>✅ Full</p>
</td>
<td style="border-style: solid; border-width: 1px;">
<p>✅ Full</p>
</td>
</tr>
<tr>
<td style="border-style: solid; border-width: 1px;">
<p>QA Schema Stability</p>
</td>
<td style="border-style: solid; border-width: 1px;">
<p>❌ Unstable</p>
</td>
<td style="border-style: solid; border-width: 1px;">
<p>✅ Stable</p>
</td>
<td style="border-style: solid; border-width: 1px;">
<p>✅ Stable</p>
</td>
</tr>
<tr>
<td style="border-style: solid; border-width: 1px;">
<p>UAT/Stakeholder Experience</p>
</td>
<td style="border-style: solid; border-width: 1px;">
<p>✅ Clean</p>
</td>
<td style="border-style: solid; border-width: 1px;">
<p>⚠️ Shares with QA</p>
</td>
<td style="border-style: solid; border-width: 1px;">
<p>❌ Shares with Prod</p>
</td>
</tr>
<tr>
<td style="border-style: solid; border-width: 1px;">
<p>Production Safety</p>
</td>
<td style="border-style: solid; border-width: 1px;">
<p>✅ Safe</p>
</td>
<td style="border-style: solid; border-width: 1px;">
<p>✅ Safe</p>
</td>
<td style="border-style: solid; border-width: 1px;">
<p>❌ Dangerous</p>
</td>
</tr>
<tr>
<td style="border-style: solid; border-width: 1px;">
<p>Application Isolation Helps?</p>
</td>
<td style="border-style: solid; border-width: 1px;">
<p>⚠️ Minimally</p>
</td>
<td style="border-style: solid; border-width: 1px;">
<p>✅ Meaningfully</p>
</td>
<td style="border-style: solid; border-width: 1px;">
<p>⚠️ Not enough</p>
</td>
</tr>
<tr>
<td style="border-style: solid; border-width: 1px;">
<p>Large Team Suitability</p>
</td>
<td style="border-style: solid; border-width: 1px;">
<p>🔴 Poor</p>
</td>
<td style="border-style: solid; border-width: 1px;">
<p>🟢 Excellent</p>
</td>
<td style="border-style: solid; border-width: 1px;">
<p>🔴 Unacceptable</p>
</td>
</tr>
</tbody>
</table>
<hr />
<h2>Implementing Automated Schema Promotion</h2>
<p>To make this pipeline robust, you should eliminate manual schema management. The recommended approach is to define all content types in code — inside your frontend components (e.g., .tsx files) — and let the <strong>Optimizely CMS CLI</strong> handle promotion programmatically.</p>
<h3>1. Integrate CLI Sync into Your CI/CD Build</h3>
<p>Your Git branch is the source of truth, and your CI/CD pipeline is the gate. Configure separate API credentials for each CMS instance in your pipeline's environment variables:</p>
<pre class="code-block"><code class="language-bash"># In your CI/CD pipeline (e.g., GitHub Actions, Azure DevOps)
# On deploy to the staging environment:
OPTIMIZELY_CMS_CLIENT_ID=${{ secrets.QA_CMS_CLIENT_ID }}
OPTIMIZELY_CMS_CLIENT_SECRET=${{ secrets.QA_CMS_CLIENT_SECRET }}
npx @optimizely/cms-cli@latest sync</code></pre>
<p>This ensures that schema changes only land on your QA+Stage instance when code is merged and deployed to your release branch — completely insulating testers from mid-sprint developer changes.</p>
<blockquote>
<p><strong>Technical Note:</strong> The CLI operates as a one-way push, reading content definitions from code and synchronizing them to the target CMS instance. This reinforces the best practice that schemas should always be version-controlled in Git.</p>
</blockquote>
<h3>2. Map Git Branches directly to CMS Instances</h3>
<p>Establishing a clear one-to-one relationship between your repository branches and your CMS targets ensures a seamless release flow:</p>
<table style="border-collapse: collapse; border-width: 1px; border-style: solid;">
<tbody>
<tr>
<td style="border-width: 1px; text-align: left; vertical-align: top; border-style: solid;">
<p><strong>Git Branch</strong></p>
</td>
<td style="border-width: 1px; text-align: left; vertical-align: top; border-style: solid;">
<p><strong>Target Frontend</strong></p>
</td>
<td style="border-width: 1px; text-align: left; vertical-align: top; border-style: solid;">
<p><strong>CLI target (CMS Instance)</strong></p>
</td>
</tr>
<tr>
<td style="border-width: 1px; text-align: left; vertical-align: top; border-style: solid;">
<p>feature/*</p>
</td>
<td style="border-width: 1px; text-align: left; vertical-align: top; border-style: solid;">
<p>Local / DEV Deploy</p>
</td>
<td style="border-width: 1px; text-align: left; vertical-align: top; border-style: solid;">
<p>DEV Instance</p>
</td>
</tr>
<tr>
<td style="border-width: 1px; text-align: left; vertical-align: top; border-style: solid;">
<p>release/* or main</p>
</td>
<td style="border-width: 1px; text-align: left; vertical-align: top; border-style: solid;">
<p>QA & Stage Deploys</p>
</td>
<td style="border-width: 1px; text-align: left; vertical-align: top; border-style: solid;">
<p>QA+Stage Shared Instance</p>
</td>
</tr>
<tr>
<td style="border-width: 1px; text-align: left; vertical-align: top; border-style: solid;">
<p>production</p>
</td>
<td style="border-width: 1px; text-align: left; vertical-align: top; border-style: solid;">
<p>Live Production Deploy</p>
</td>
<td style="border-width: 1px; text-align: left; vertical-align: top; border-style: solid;">
<p>Prod Instance</p>
</td>
</tr>
</tbody>
</table>
<hr />
<h2>Aligning SaaS Architecture with Team Requirements</h2>
<p>This approach reflects the cloud-native, headless architecture of modern SaaS platforms: the CMS backend is tightly integrated with global content APIs, real-time preview engines, and the Optimizely Graph layer.</p>
<p>By utilizing branch-gated CI/CD pipelines and native CMS Applications, teams can deliver enterprise-grade release management that feels fast, automated, and safe.</p>
<p>For large global organizations where a strictly isolated 4-environment physical topology is required by compliance or parallel testing tracks, we recommend discussing your roadmap early with your Optimizely account team. Additional non-production instances can easily be provisioned, and framing the discussion around team velocity and schema-gated testing ensures a highly collaborative path forward.</p>
<hr />
<h2>Summary of Best Practices</h2>
<ul class="tight">
<li>
<p><strong>Differentiate applications from environments:</strong> Use separate Applications to isolate content trees, but remember schemas are instance-wide.</p>
</li>
<li>
<p><strong>Isolate development first:</strong> Keep your DEV instance fully separated so developers have complete freedom to innovate and experiment.</p>
</li>
<li>
<p><strong>Automate schema delivery:</strong> Define content types in code and use the <strong>Optimizely CMS CLI</strong> to synchronize schemas at build time.</p>
</li>
<li>
<p><strong>Gate with Git:</strong> Align your branching strategy directly with your CMS targets to turn your pipeline into a hands-free, automated release gate.</p>
</li>
</ul>
<hr />
<p><em>How has your team structured its headless deployment pipeline? Share your architecture tips and lessons learned in the comments below!</em></p>2026-07-12T02:38:20.0000000ZBlog postBynder DAM Connector for Optimizely SaaS CMS: Improved Metadata Property Synchronization<p>While working with the <strong>Bynder DAM Connector for Optimizely SaaS CMS</strong>, one of the key areas I explored was how Bynder asset metadata is synchronized into <strong>Optimizely Graph</strong>.</p>
<p>The connector already makes it possible to synchronize Bynder assets into Optimizely and expose them through Graph. However, during implementation validation, we came across an important limitation around metadata property synchronization.</p>
<h2>The Previous Limitation</h2>
<p>Earlier, when configuring the synchronization between Bynder and Optimizely, only <strong>Bynder date-type metadata properties</strong> were available for syncing into the Optimizely Graph schema.</p>
<p>This created a challenge because real-world DAM implementations rarely depend only on date fields.</p>
<p>Most enterprise DAM metadata models use a combination of:</p>
<ul>
<li>Text fields</li>
<li>Date fields</li>
<li>Single-select fields</li>
<li>Multi-select fields</li>
<li>Taxonomy-like option fields</li>
<li>Classification fields</li>
<li>Asset usage fields</li>
<li>Product/category metadata</li>
</ul>
<p>For a website implementation, this metadata is often required by the frontend application for rendering, filtering, searching, or making delivery decisions.</p>
<p>For example, teams may need metadata such as:</p>
<div class="___77lcry0 f10pi13n">
<div class="___1hewfwb f10pi13n f7oukh6 f5p0z4x">
<div>
<div class="scriptor-component-code-block _7CA39p32MJD4WzQj430bEw== scriptor-codeblock-virtualized">
<div class="_8cbhMyAb-O4gAE0YhMz5Fw== qMbZ7GayOiqoFAta+ROcfQ== FXk3ZkPfVa3dK4NENK0BuA== RV6aOXRSOKYambFOGypRUQ==">
<div class="PR-eQAguLtV9jbLyecurDA== IWL7hnrJGkNIEXimV4iK3g== wyvwRXSwbmbyvZ+nt0gDjg==">
<div class="i6fZNmFRGK4PfVuJHFCJ7A==">
<div class="JnZEfplZ8eOYvZUyrK1wMQ== j0h+RXQ+O2kKSwB+JVlQsg== J61nEcw0wYMHfeNRQL3FdA==">
<ul>
<li class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">Asset type</li>
<li class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">Product family</li>
<li class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">Language</li>
<li class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">Region</li>
<li class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">Usage rights</li>
<li class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">Document category</li>
<li class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">Video category</li>
<li class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">Public/private status</li>
<li class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">Website readiness</li>
</ul>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p>If only date fields are available during synchronization, then the DAM metadata model cannot be fully represented in Optimizely Graph.</p>
<div>
<div><hr /></div>
</div>
<h2>What Has Improved</h2>
<p>The Optimizely team has now improved the Bynder connector metadata synchronization behavior.</p>
<p>Metadata properties from Bynder can now be selected across multiple field types, including:</p>
<div class="___77lcry0 f10pi13n">
<div class="___1hewfwb f10pi13n f7oukh6 f5p0z4x">
<div>
<div class="scriptor-component-code-block _7CA39p32MJD4WzQj430bEw== scriptor-codeblock-virtualized">
<div class="_8cbhMyAb-O4gAE0YhMz5Fw== qMbZ7GayOiqoFAta+ROcfQ== FXk3ZkPfVa3dK4NENK0BuA== RV6aOXRSOKYambFOGypRUQ==">
<div class="PR-eQAguLtV9jbLyecurDA== IWL7hnrJGkNIEXimV4iK3g== wyvwRXSwbmbyvZ+nt0gDjg==">
<div class="i6fZNmFRGK4PfVuJHFCJ7A==">
<div class="JnZEfplZ8eOYvZUyrK1wMQ== j0h+RXQ+O2kKSwB+JVlQsg== J61nEcw0wYMHfeNRQL3FdA==">
<ul>
<li class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">Date</li>
<li class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">Text</li>
<li class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">Single select</li>
<li class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">Multiple select</li>
</ul>
<div>
<div><hr /></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<div>
<h2>How Different Property Types Behave</h2>
<h4>1) Date Properties</h4>
<p>Date properties synchronize the date value from Bynder. In Optimizely content type the type will become a string type.</p>
<h4>2) Text Properties</h4>
<p>Text properties synchronize the value entered by the author or DAM user in Bynder.</p>
<h4>3) Single Select and Multiple Select Properties</h4>
<p>Single-select and multiple-select properties behave differently.</p>
<p>For these fields, the synchronized values represent the <strong>database names</strong> for the selected options, not the display labels shown to users in the Bynder interface.</p>
<p>For example, </p>
<p>Bynder option label: Case Study </p>
<p>Synchronized value: Case_Study</p>
<p>This can be useful for backend logic, integrations, filtering, or stable system-level matching.</p>
<p>However, these values may not always be ideal for direct frontend rendering, especially if the frontend needs human-readable labels or multilingual labels</p>
<div>
<div><hr /></div>
</div>
<div>
<h2>Important Note on Labels</h2>
<p>For <strong>single-select</strong> and <strong>multiple-select</strong> metadata properties, if the frontend application needs the actual option labels, those labels should be retrieved separately using the <strong>Bynder API</strong>.</p>
<p>This is especially important when labels are maintained in multiple languages.</p>
<p>This label-resolution topic deserves its own separate discussion because it involves option IDs, database names, display labels, multilingual labels, and frontend rendering decisions.</p>
<hr /></div>
</div>
<h2>What About Option IDs?</h2>
<p>The connector also provides a standard property called:</p>
<div class="___77lcry0 f10pi13n">
<div class="___1hewfwb f10pi13n f7oukh6 f5p0z4x">
<div>
<div class="scriptor-component-code-block _7CA39p32MJD4WzQj430bEw== scriptor-codeblock-virtualized">
<div class="_8cbhMyAb-O4gAE0YhMz5Fw== qMbZ7GayOiqoFAta+ROcfQ== FXk3ZkPfVa3dK4NENK0BuA== RV6aOXRSOKYambFOGypRUQ==">
<div class="PR-eQAguLtV9jbLyecurDA== IWL7hnrJGkNIEXimV4iK3g== wyvwRXSwbmbyvZ+nt0gDjg==">
<div class="i6fZNmFRGK4PfVuJHFCJ7A==">
<div class="JnZEfplZ8eOYvZUyrK1wMQ== j0h+RXQ+O2kKSwB+JVlQsg== J61nEcw0wYMHfeNRQL3FdA==">
<div class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">
<ul>
<li>PropertyOptions</li>
</ul>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p>This property returns a consolidated list of option IDs selected across available single-select and multi-select metadata fields.</p>
<p>Following screenshot shows how Grpah stores the data in propertyOptions field.</p>
<figure class="image align-left"><img style="border-width: 1px; border-style: solid;" src="/link/71858b04167a4faa915999c7188bb96b.aspx?1783753202657" alt="Graph stores all selected options ids inside "propertyOptions"" width="711" height="156" />
<figcaption>Graph stroes all seleted option ids inside "propertyOptions" property</figcaption>
</figure>
<div>
<h2> </h2>
<h2> </h2>
<h2> </h2>
<h2> </h2>
<h2> </h2>
<div>
<div><hr /></div>
</div>
<h2>Why This Fix Matters</h2>
<p>This improvement makes the Bynder DAM Connector more practical for real-world Optimizely SaaS CMS implementations.</p>
<p>It allows teams to bring more useful metadata into Optimizely Graph without being limited only to date fields.</p>
<p>This helps with:</p>
<div class="___77lcry0 f10pi13n">
<div class="___1hewfwb f10pi13n f7oukh6 f5p0z4x">
<div class="scriptor-component-code-block _7CA39p32MJD4WzQj430bEw== scriptor-codeblock-virtualized">
<div class="_8cbhMyAb-O4gAE0YhMz5Fw== qMbZ7GayOiqoFAta+ROcfQ== FXk3ZkPfVa3dK4NENK0BuA== RV6aOXRSOKYambFOGypRUQ==">
<div class="PR-eQAguLtV9jbLyecurDA== IWL7hnrJGkNIEXimV4iK3g== wyvwRXSwbmbyvZ+nt0gDjg==">
<div class="i6fZNmFRGK4PfVuJHFCJ7A==">
<div class="JnZEfplZ8eOYvZUyrK1wMQ== j0h+RXQ+O2kKSwB+JVlQsg== J61nEcw0wYMHfeNRQL3FdA==">
<ul>
<li class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">Better asset classification</li>
<li class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">Cleaner frontend logic</li>
<li class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">Improved filtering</li>
<li class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">Better integration support</li>
<li class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">More flexible content delivery</li>
<li class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">Reduced custom workarounds</li>
</ul>
<div class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">The key improvement is that implementation teams can now synchronize more metadata property types from Bynder into Optimizely Graph and decide which metadata is useful for CMS, frontend, or integration scenarios.
<div>
<div><hr /></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<h2>You Do Not Need to Sync Everything</h2>
<p>Another important point is that metadata synchronization does not need to be all-or-nothing.</p>
<p>Implementation teams can choose which Bynder metadata properties should be synchronized into Optimizely.</p>
<p>This is important because not every DAM metadata field is useful for website rendering or content delivery.</p>
<p>For example, a DAM may contain metadata for:</p>
<div class="___77lcry0 f10pi13n">
<div class="___1hewfwb f10pi13n f7oukh6 f5p0z4x">
<div>
<div class="scriptor-component-code-block _7CA39p32MJD4WzQj430bEw== scriptor-codeblock-virtualized">
<div class="_8cbhMyAb-O4gAE0YhMz5Fw== qMbZ7GayOiqoFAta+ROcfQ== FXk3ZkPfVa3dK4NENK0BuA== RV6aOXRSOKYambFOGypRUQ==">
<div class="PR-eQAguLtV9jbLyecurDA== IWL7hnrJGkNIEXimV4iK3g== wyvwRXSwbmbyvZ+nt0gDjg==">
<div class="i6fZNmFRGK4PfVuJHFCJ7A==">
<div class="JnZEfplZ8eOYvZUyrK1wMQ== j0h+RXQ+O2kKSwB+JVlQsg== J61nEcw0wYMHfeNRQL3FdA==">
<ul>
<li class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">Internal workflows</li>
<li class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">Asset production</li>
<li class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">Legal approval</li>
<li class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">Agency ownership</li>
<li class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">Archive management</li>
<li class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">Regional campaigns</li>
<li class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">Website delivery</li>
</ul>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p>Only a subset of those fields may be needed in Optimizely Graph.</p>
<p>The better approach is to intentionally select the metadata fields that are required for:</p>
<ul>
<li>Frontend rendering</li>
<li>Content authoring</li>
<li>Filtering</li>
<li>Search</li>
<li>Asset classification</li>
<li>Delivery rules</li>
<li>Public/restricted asset decisions</li>
<li>Video or document handling</li>
</ul>
<p>This avoids unnecessary metadata noise and keeps the Graph schema cleaner.</p>
<div>
<div><hr /></div>
</div>
<h2>Application User Interface for field Mapping</h2>
<p>Here is a screenshot form the application for field mapping step which shows the simple user intrface to select what metadata properties from Bynder needs to be synced in Optimizely Graph.</p>
<p>In below screenshot:</p>
<ul>
<li>All custom metadata fields are indicated with an asterisk (*) <em>at the end of the metadata property name e.g. AltText*</em></li>
<li>You can choose which property you want to keep into your schema or not so that sync will only store the relevant data in Optimizely Graph.</li>
<li>You can not enter the property names. Application will automatcially generate that for you based on your property name and prepending that with "property_".</li>
<li>As you can see in below screenshot the PropertyOptions is standard Bynder asset property, there is no asterisk (*) with it.</li>
</ul>
<p><img style="border-width: 1px; border-style: solid;" src="/link/59c02bbfdeed45f5ba2431bb3bb5e394.aspx?1783749874850" width="1103" height="1033" /></p>
<div>
<p><strong>Asset data synced in Grpah (including the standard and the custom properties) <br /></strong>*This screenshot is added just for illustration purpose only </p>
<p><img style="border-width: 1px; border-style: solid;" src="/link/460ca686863f41b087c124c09a031596.aspx" alt="" width="719" height="1384" /></p>
<hr /></div>
<div>
<h2>Recommended Implementation Approach</h2>
<p>Before enabling broad metadata synchronization, teams should define a simple metadata sync strategy.</p>
<p>Recommended steps:</p>
<div class="___77lcry0 f10pi13n">
<div class="___1hewfwb f10pi13n f7oukh6 f5p0z4x">
<div>
<div class="scriptor-component-code-block _7CA39p32MJD4WzQj430bEw== scriptor-codeblock-virtualized">
<div class="_8cbhMyAb-O4gAE0YhMz5Fw== qMbZ7GayOiqoFAta+ROcfQ== FXk3ZkPfVa3dK4NENK0BuA== RV6aOXRSOKYambFOGypRUQ==">
<div class="PR-eQAguLtV9jbLyecurDA== IWL7hnrJGkNIEXimV4iK3g== wyvwRXSwbmbyvZ+nt0gDjg==">
<div class="i6fZNmFRGK4PfVuJHFCJ7A==">
<div class="JnZEfplZ8eOYvZUyrK1wMQ== j0h+RXQ+O2kKSwB+JVlQsg== J61nEcw0wYMHfeNRQL3FdA==">
<ul>
<li class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">Review available Bynder metadata properties.</li>
<li class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">Identify which fields are required by Optimizely CMS, Optimizely Graph, or the frontend application.</li>
<li class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">Decide which fields should be synchronized.</li>
<li class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">Confirm how each field type appears in Optimizely Graph.</li>
<li class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">For single-select and multiple-select fields, decide whether database values are sufficient.</li>
<li class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">If frontend labels are required, plan label resolution using Bynder API.</li>
</ul>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<div class="___77lcry0 f10pi13n">
<div class="___1hewfwb f10pi13n f7oukh6 f5p0z4x">
<div>
<div class="scriptor-component-code-block _7CA39p32MJD4WzQj430bEw== scriptor-codeblock-virtualized">
<div class="_8cbhMyAb-O4gAE0YhMz5Fw== qMbZ7GayOiqoFAta+ROcfQ== FXk3ZkPfVa3dK4NENK0BuA== RV6aOXRSOKYambFOGypRUQ==">
<div class="PR-eQAguLtV9jbLyecurDA== IWL7hnrJGkNIEXimV4iK3g== wyvwRXSwbmbyvZ+nt0gDjg==">
<div class="i6fZNmFRGK4PfVuJHFCJ7A==">
<div class="JnZEfplZ8eOYvZUyrK1wMQ== j0h+RXQ+O2kKSwB+JVlQsg== J61nEcw0wYMHfeNRQL3FdA=="> </div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<h2>Example Metadata Sync Strategy</h2>
<p>For a website implementation, the team may decide to sync fields such as:</p>
<div class="___77lcry0 f10pi13n">
<div class="___1hewfwb f10pi13n f7oukh6 f5p0z4x">
<div>
<div class="scriptor-component-code-block _7CA39p32MJD4WzQj430bEw== scriptor-codeblock-virtualized">
<div class="_8cbhMyAb-O4gAE0YhMz5Fw== qMbZ7GayOiqoFAta+ROcfQ== FXk3ZkPfVa3dK4NENK0BuA== RV6aOXRSOKYambFOGypRUQ==">
<div class="PR-eQAguLtV9jbLyecurDA== IWL7hnrJGkNIEXimV4iK3g== wyvwRXSwbmbyvZ+nt0gDjg==">
<div class="i6fZNmFRGK4PfVuJHFCJ7A==">
<div class="JnZEfplZ8eOYvZUyrK1wMQ== j0h+RXQ+O2kKSwB+JVlQsg== J61nEcw0wYMHfeNRQL3FdA==">
<ul>
<li class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">Asset title</li>
<li class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">Asset description</li>
<li class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">Asset type</li>
<li class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">Language</li>
<li class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">Region</li>
<li class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">Public/private classification</li>
<li class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">Website-ready flag</li>
<li class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">Video ID</li>
<li class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">Document category</li>
<li class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">Product association</li>
<li class="tY5faFHEOPAHuO+tqkg+jA== DhgBbNGs9GW303hvyw6gHA==">Application association</li>
</ul>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p>But avoid syncing fields that are only relevant to internal DAM operations.</p>
<div>
<div><hr /></div>
</div>
<h2>Why This Is a Good Improvement</h2>
<p>This connector update improves the practical usability of Bynder DAM metadata inside Optimizely SaaS CMS implementations.</p>
<p>It helps teams:</p>
<ul>
<li>Use richer metadata in Optimizely Graph</li>
<li>Avoid custom mapping workarounds</li>
<li>Keep frontend logic cleaner</li>
<li>Use business-readable labels where needed</li>
<li>Still access option IDs through <strong>"propertyOptions"</strong></li>
<li>Select only the metadata fields that matter</li>
<li>Better support real enterprise DAM models</li>
</ul>
<div>
<div><hr /></div>
</div>
<div>
<h2>Final Thought</h2>
<p>This connector improvement is a valuable step forward for teams integrating <strong>Bynder DAM with Optimizely SaaS CMS</strong>.</p>
<p>Being able to synchronize more metadata property types into Optimizely Graph gives implementation teams more flexibility and reduces the need for custom workarounds.</p>
<p>The key takeaway is simple:</p>
<p><strong>The Bynder DAM Connector can now synchronize more metadata property types into Optimizely Graph, but teams should still be intentional about which metadata they sync and how those values will be used.</strong></p>
<p><strong>For single-select and multiple-select fields, the synchronized values are useful for system logic, but frontend-friendly labels may still require a separate lookup through the Bynder API.</strong></p>
</div>2026-07-11T07:31:39.0000000ZBlog postOptimizely Content JS SDK v2.1.0 — What's New and Why It Matters<p> </p>
<p>v2.1.0 of the Optimizely Content JS SDK and CLI landed on July 7, 2026. This is a substantial release bringing a wave of capabilities for developers building headless experiences on Optimizely CMS SaaS — including content type contracts, programmatic application management, a new project scaffolding command, and OpenTelemetry observability.</p>
<p>Alongside these major features, the release addresses critical stability fixes that resolve key edge cases in content fetching, previews, and routing. Below is a deep dive into what has changed, why these updates matter, and how they improve your development workflow.</p>
<hr />
<h2>Content Type Sprawl and the New Contract Enhancements</h2>
<p>If you've been building with the SDK for a while, you've probably felt this. Your content model grows. You have a Blog content type, a News Article, a Press Release. They're different types, but they share a bunch of the same properties — <strong>category</strong>, <strong>tags</strong>, <strong>author</strong>, <strong>publishedDate</strong>. So you define those properties three separate times across three separate <strong>contentType()</strong> calls. Then a product manager asks you to add a region field to all of them, and you make the same change in three places and hope you didn't miss one.</p>
<p>While you could previously declare shared interfaces, <strong>v2.1.0 introduces major enhancements to how the SDK handles content type contracts</strong> at runtime to eliminate this duplicate work:</p>
<ul class="tight">
<li>
<p><strong>Allowed and restricted types on contracts</strong> — specify exactly which content types can or must implement a contract</p>
</li>
<li>
<p><strong>Automatic GraphQL fragment generation</strong> — when you query a contracted type, the SDK auto-generates the correct inline fragments so all implementing types return their contracted fields without manual query writing</p>
</li>
<li>
<p><strong>Component fallback mechanism</strong> — if a content item implements a contract but you haven't registered a specific React component for that particular type, the SDK now falls back to a contract-level component rather than rendering nothing. Silent blank renders caused by missing component registrations were a real source of confusion — this addresses that.</p>
</li>
</ul>
<p>On the CLI side, the <strong>pull</strong> command now generates and validates contract definitions as part of your code generation step. One sync, and your contracts are in code.</p>
<p><a href="https://github.com/episerver/content-js-sdk/pull/292"><em>CMS-46677, PR #292</em></a></p>
<hr />
<h2>Programmatic Application Management via CLI</h2>
<p><strong>The Context: </strong>The SDK and CLI provide a highly automated workflow for managing content types in code, but CMS applications (the configuration mapping your frontend hostnames to CMS start pages) historically required manual configuration in the CMS admin UI.</p>
<p>For teams running multiple environments (Development, Staging, Production) or spinning up ephemeral environments for feature branches, this manual step was a deployment bottleneck. If a team member created an environment, they had to manually configure the application in the UI or routing wouldn't resolve. It wasn't version-controlled, automated, or easily reproducible.</p>
<p><strong>The Solution: </strong>v2.1.0 introduces full <strong>application type definitions and validation</strong> to the SDK and exposes three new programmatic management commands in the CLI:</p>
<pre class="code-block"><code class="language-bash">cms-cli createApplication # Create a new CMS application programmatically
cms-cli updateApplication # Update an existing application's configuration
cms-cli checkApplications # Validate registered applications against your local config</code></pre>
<p><em class="far4bl _667h42">**Refer to the <a class="_667h42 _1l4j4nad _1c9dtv3 _1by2b93 _1140xq1 _667h42" href="https://docs.developers.optimizely.com/content-management-system/v1.0.0-CMS-SaaS/docs/configure-javascript-sdk">official CLI documentation</a> for exact command syntax and options.</em></p>
<p>Your application configuration can now live in code with the rest of your schema. For teams running automated CI/CD pipelines, this closes a significant orchestration gap.</p>
<p><a href="https://github.com/episerver/content-js-sdk/pull/333"><em>CMS-51342, PR #333</em></a></p>
<hr />
<h2>A Seamless Editing Experience with NextPreviewComponent</h2>
<p><strong>The Context:</strong>In headless setups, keeping the live preview fast and interactive is critical for content editors. However, standard preview routing setups in Next.js App Router projects often triggered full page reloads upon saving content drafts in the CMS. Editors had to wait for the entire route to re-render and often lost their scroll position or current tab context.</p>
<p><strong>The Solution:</strong>v2.1.0 ships the <strong>NextPreviewComponent</strong>, a preview component specifically optimized for the Next.js App Router rendering lifecycle:</p>
<ul class="tight">
<li>
<p><strong>Optimized save-event listener</strong> — hooks into the content-saved webhook efficiently to detect draft saves immediately without polling</p>
</li>
<li>
<p><strong>Soft refresh support</strong> — updates draft content on-screen in place. The editor sees their changes reflect instantly without a full browser reload or losing scroll position</p>
</li>
</ul>
<p>This significantly reduces the friction of the editorial feedback loop, making visual editing in CMS SaaS feel smooth and instant.</p>
<p><a href="https://github.com/episerver/content-js-sdk/pull/319"><em>CMS-52407, PR #319</em></a></p>
<hr />
<h2>Observability Built In: OpenTelemetry Support</h2>
<p><strong>The Context: </strong>Performance tuning in decoupled architectures is notoriously difficult. If a page load feels laggy, it can be hard to identify whether the delay is happening during client-side hydration, SDK query construction, network latency to Optimizely Graph, or <span class="far4bl _667h42">the query processing time within Optimizely Graph</span>. Without deep instrumentation, developers are left guessing or manually wrapping every <strong>getContentByPath()</strong> call in custom tracing blocks.</p>
<p><strong>The Solution: </strong>The SDK now features native <strong>OpenTelemetry (OTEL) tracing and metrics</strong>. If your hosting environment or application infrastructure runs an OTEL-compatible collector (such as Datadog, New Relic, Honeycomb, Grafana, or Jaeger), the SDK's fetch layer will automatically emit trace spans.</p>
<p>You can now natively profile the duration of your content queries, see exactly how long Optimizely Graph takes to respond, and spot any nested reference fetches that are impacting your latency budget.</p>
<p><a href="https://github.com/episerver/content-js-sdk/pull/309"><em>CMS-50199, PR #309</em></a></p>
<hr />
<h2>Getting Started Faster with create-opti-app</h2>
<p><strong>The Context: </strong>Historically, starting a new project on CMS SaaS required cloning a complete demo repository, stripping out demo content and styling, configuring environment variables from scratch, and adjusting boilerplates. It lacked a lightweight, standardized onboarding command.</p>
<p><strong>The Solution: </strong>The CLI now features a dedicated onboarding and scaffolding utility:</p>
<pre class="code-block"><code class="language-bash">npx @optimizely/cms-cli@latest create-opti-app</code></pre>
<p>This utility lets you quickly scaffold a clean, working project from three officially maintained starter templates:</p>
<ul class="tight">
<li>
<p><strong>Stride</strong> — The modern recommended starter preconfigured for Visual Builder</p>
</li>
<li>
<p><strong>Alloy</strong> — The classic Optimizely demonstration site</p>
</li>
<li>
<p><strong>TanStack</strong> — TanStack Router + React for projects opting out of Next.js</p>
</li>
</ul>
<p>These templates are maintained alongside the core SDK, ensuring they stay aligned with the latest framework best practices.</p>
<p><a href="https://github.com/episerver/content-js-sdk/pull/382"><em>CMS-49618, PR #382</em></a></p>
<hr />
<h2>Key Stability and Bug Fixes</h2>
<p>Behind the major feature updates, v2.1.0 delivers key bug fixes addressing critical routing, caching, and serialization edge cases.</p>
<h3>Correcting getContent() Versioning Behavior</h3>
<p><strong>The Problem:</strong> In certain configurations, the <strong>getContent()</strong> method (which retrieves a content item by its programmatic ID) was returning the <strong>draft version</strong> of a page or block to anonymous public visitors rather than the active published version. If an editor had an in-progress draft saved in the CMS, those unapproved changes <span class="far4bl _667h42">could unintentionally appear on the live website</span>.</p>
<p><strong>The Fix:</strong> The SDK has been corrected to ensure <strong>getContent()</strong> strictly returns the published version of content for public delivery, safeguarding editorial workflows.</p>
<p><a href="https://github.com/episerver/content-js-sdk/pull/307"><em>CMS-52026, PR #307</em></a></p>
<hr />
<h3>Resolving getContentByPath() 404s on Simple Addresses</h3>
<p><strong>The Problem:</strong> Optimizely CMS allows editors to assign a "simple address" to any page (e.g., a short URL alias like <strong>/about</strong> instead of a long hierarchical path). When a page used a simple address, <strong>getContentByPath()</strong> was throwing a 404 error, breaking routing for pages where custom slugs had been configured.</p>
<p><strong>The Fix:</strong> Path-resolution logic has been updated to correctly resolve pages using CMS simple addresses, ensuring routing works smoothly across all customized URLs.</p>
<p><a href="https://github.com/episerver/content-js-sdk/pull/312"><em>CMS-52209, PR #312</em></a></p>
<hr />
<h3>Resolving Empty DAM Asset References in Compositions</h3>
<p><strong>The Problem:</strong> When assets from Digital Asset Management (DAM) systems were referenced inside Visual Builder compositions (experiences structured using rows, columns, and sections), the returned fields occasionally resolved as <strong>null</strong> or empty. The query was executing successfully, but the auto-generated GraphQL query was missing the necessary inline fragments to serialize the nested DAM properties.</p>
<p><strong>The Fix:</strong> The query generator has been updated to guarantee proper DAM asset fragment resolution inside experience compositions.</p>
<p><a href="https://github.com/episerver/content-js-sdk/pull/318"><em>CMS-52404, PR #318</em></a></p>
<hr />
<h3>Circular Reference Support in Code Generation</h3>
<p><strong>The Problem:</strong> In complex content models, types frequently reference each other circularly (for example, a <strong>Category</strong> type containing a <strong>parentCategory</strong> property of type <strong>Category</strong>, or a <strong>MenuItem</strong> pointing to child <strong>MenuItems</strong>). When the CLI encountered these models, the code generator would enter an infinite loop or fail to compile the output.</p>
<p><strong>The Fix:</strong> Both the SDK and CLI have been updated to support circular and self-referential content types by outputting string-based type references at the boundary of a detected cycle, allowing code generation to compile cleanly.</p>
<p><em><a href="https://github.com/episerver/content-js-sdk/pull/409">SDK: CMS-53737, PR #409 </a>· <a href="https://github.com/episerver/content-js-sdk/pull/305">CLI: CMS-44353, PR #305</a></em></p>
<hr />
<h3>Consistent RichText HTML Entity Decoding</h3>
<p><strong>The Problem:</strong> Certain encoded HTML entities (such as non-breaking spaces <strong>&nbsp;</strong>, em dashes <strong>&ndash;</strong>, or custom characters) inside <strong>RichText</strong> properties were decoded inconsistently, sometimes rendering raw entity markup directly to the page.</p>
<p><strong>The Fix:</strong> The entity decoding logic inside the <strong>RichText</strong> parser has been standardized to ensure consistent rendering across all HTML entities.</p>
<p><a href="https://github.com/episerver/content-js-sdk/pull/353"><em>CMS-53226, PR #353</em></a></p>
<hr />
<h3>Preview Mode: Synchronized Element Focus and Attributes</h3>
<p><strong>The Problem:</strong> In preview mode, two visual editing issues impacted the editor experience:</p>
<ol class="tight">
<li>
<p>Selecting an element in the Visual Builder sidebar didn't reliably focus or highlight that corresponding element inside the live iframe.</p>
</li>
<li>
<p>Visual editing attributes (<strong>data-epi-*</strong> metadata) were missing from custom <strong>OptimizelyComposition</strong> and <strong>OptimizelyGridSection</strong> wrappers, rendering some on-page edit boundaries inactive.</p>
</li>
</ol>
<p><strong>The Fix:</strong> The preview attribute delivery and sidebar communication have been fully synchronized. On-page edit boundaries now map perfectly to the visual structure, and sidebar element selections correctly shift iframe focus.</p>
<p><em><a href="https://github.com/episerver/content-js-sdk/pull/346">Focus: CMS-52749, PR #346 </a>· <a href="https://github.com/episerver/content-js-sdk/pull/393">Attributes: CMS-53437, PR #393</a></em></p>
<hr />
<h3>Fallback Resolution for types ending in "...Property"</h3>
<p><strong>The Problem:</strong> If a custom content type name ended with the suffix <strong>"Property"</strong> (e.g., <strong>HeroImageProperty</strong>, the component registry's fallback resolver incorrectly classified it as a system property type rather than a content element, failing to resolve a fallback component.</p>
<p><strong>The Fix:</strong> The matching algorithms have been refined to ensure custom content types ending in "Property" correctly evaluate and resolve fallback layouts.</p>
<p><a href="https://github.com/episerver/content-js-sdk/pull/304"><em>CMS-51995, PR #304</em></a></p>
<hr />
<h2>Additional Improvements</h2>
<table style="border-collapse: collapse; border-width: 1px; border-spacing: 5px; border-style: solid;">
<tbody>
<tr>
<td style="border-style: solid; border-width: 1px; text-align: left; vertical-align: top; padding: 1px;">
<p><strong>Change</strong></p>
</td>
<td style="border-style: solid; border-width: 1px; text-align: left; vertical-align: top; padding: 1px;">
<p><strong>Problem</strong></p>
</td>
<td style="border-style: solid; border-width: 1px; text-align: left; vertical-align: top; padding: 1px;">
<p><strong>Solution</strong></p>
</td>
</tr>
<tr>
<td style="border-style: solid; border-width: 1px; text-align: left; vertical-align: top; padding: 1px;">
<p><strong>Base type properties in queries</strong></p>
<p><strong><a href="https://github.com/episerver/content-js-sdk/pull/392">CMS-41847, PR #392</a></strong></p>
</td>
<td style="border-style: solid; border-width: 1px; text-align: left; vertical-align: top; padding: 1px;">
<p>Some inherited base type fields were missing from auto-generated GraphQL queries, requiring manual query extensions</p>
</td>
<td style="border-style: solid; border-width: 1px; text-align: left; vertical-align: top; padding: 1px;">
<p>All base type properties are now automatically included</p>
</td>
</tr>
<tr>
<td style="border-style: solid; border-width: 1px; text-align: left; vertical-align: top; padding: 1px;">
<p><strong>Locale on ContentType</strong></p>
<p><strong><a href="https://github.com/episerver/content-js-sdk/pull/400">CMS-53704, PR #400</a></strong></p>
</td>
<td style="border-style: solid; border-width: 1px; text-align: left; vertical-align: top; padding: 1px;">
<p>No way to specify locale at the type definition level for multilingual setups</p>
</td>
<td style="border-style: solid; border-width: 1px; text-align: left; vertical-align: top; padding: 1px;">
<p><strong>ContentType</strong> and <strong>RICHTEXT_PRESET</strong> now accept an optional <strong>locale</strong> parameter</p>
</td>
</tr>
<tr>
<td style="border-style: solid; border-width: 1px; text-align: left; vertical-align: top; padding: 1px;">
<p><strong>Section fragments in compositions</strong></p>
<p><strong><a href="https://github.com/episerver/content-js-sdk/pull/388">CMS-53436, PR #388</a></strong></p>
</td>
<td style="border-style: solid; border-width: 1px; text-align: left; vertical-align: top; padding: 1px;">
<p>Sections inside Visual Builder experiences didn't generate proper GraphQL fragments</p>
</td>
<td style="border-style: solid; border-width: 1px; text-align: left; vertical-align: top; padding: 1px;">
<p>Section fragment handling added to <strong>OptimizelyComposition</strong></p>
</td>
</tr>
<tr>
<td style="border-style: solid; border-width: 1px; text-align: left; vertical-align: top; padding: 1px;">
<p><strong>Display template for experiences</strong></p>
<p><strong><a href="https://github.com/episerver/content-js-sdk/pull/335">CMS-52750, PR #335</a></strong></p>
</td>
<td style="border-style: solid; border-width: 1px; text-align: left; vertical-align: top; padding: 1px;">
<p>Top-level experience content didn't respect its assigned display template</p>
</td>
<td style="border-style: solid; border-width: 1px; text-align: left; vertical-align: top; padding: 1px;">
<p>Display template resolution now works for top-level experiences</p>
</td>
</tr>
<tr>
<td style="border-style: solid; border-width: 1px; text-align: left; vertical-align: top; padding: 1px;">
<p><strong>Type re-exports</strong></p>
<p><strong><a href="https://github.com/episerver/content-js-sdk/pull/405">CMS-53656, PR #405</a></strong></p>
</td>
<td style="border-style: solid; border-width: 1px; text-align: left; vertical-align: top; padding: 1px;">
<p>Missing re-exports caused broken <strong>.d.ts</strong> declaration files in consuming projects</p>
</td>
<td style="border-style: solid; border-width: 1px; text-align: left; vertical-align: top; padding: 1px;">
<p>Type re-exports added for proper declaration file generation</p>
</td>
</tr>
<tr>
<td style="border-style: solid; border-width: 1px; text-align: left; vertical-align: top; padding: 1px;">
<p><strong>Empty contracts config</strong></p>
<p><strong><a href="https://github.com/episerver/content-js-sdk/pull/342">CMS-52849, PR #342</a></strong></p>
</td>
<td style="border-style: solid; border-width: 1px; text-align: left; vertical-align: top; padding: 1px;">
<p>Passing an empty contracts array in config threw an error</p>
</td>
<td style="border-style: solid; border-width: 1px; text-align: left; vertical-align: top; padding: 1px;">
<p>Empty contracts are now allowed without errors</p>
</td>
</tr>
<tr>
<td style="border-style: solid; border-width: 1px; text-align: left; vertical-align: top; padding: 1px;">
<p><strong>Self-signed certificates (CLI)</strong></p>
<p><strong><a href="https://github.com/episerver/content-js-sdk/pull/322">CMS-52494, PR #322</a></strong></p>
</td>
<td style="border-style: solid; border-width: 1px; text-align: left; vertical-align: top; padding: 1px;">
<p>CLI couldn't connect to CMS instances behind self-signed certs in dev/staging</p>
</td>
<td style="border-style: solid; border-width: 1px; text-align: left; vertical-align: top; padding: 1px;">
<p>Self-signed certificate support added</p>
</td>
</tr>
<tr>
<td style="border-style: solid; border-width: 1px; text-align: left; vertical-align: top; padding: 1px;">
<p><strong>RichText editor settings (CLI)</strong></p>
<p><strong><a href="https://github.com/episerver/content-js-sdk/pull/348">CMS-52547, PR #348</a></strong></p>
</td>
<td style="border-style: solid; border-width: 1px; text-align: left; vertical-align: top; padding: 1px;">
<p>No way to configure editor settings for RichText properties via the CLI</p>
</td>
<td style="border-style: solid; border-width: 1px; text-align: left; vertical-align: top; padding: 1px;">
<p>Editor settings for RichText are now supported</p>
</td>
</tr>
<tr>
<td style="border-style: solid; border-width: 1px; text-align: left; vertical-align: top; padding: 1px;">
<p><strong>Duplicate applications (CLI)</strong></p>
<p><strong><a href="https://github.com/episerver/content-js-sdk/pull/403">CMS-53768, PR #403</a></strong></p>
</td>
<td style="border-style: solid; border-width: 1px; text-align: left; vertical-align: top; padding: 1px;">
<p>CLI threw errors when multiple applications shared entry points or had missing entry points</p>
</td>
<td style="border-style: solid; border-width: 1px; text-align: left; vertical-align: top; padding: 1px;">
<p>Duplicate handling and missing entry point filtering added</p>
</td>
</tr>
<tr>
<td style="border-style: solid; border-width: 1px; text-align: left; vertical-align: top; padding: 1px;">
<p><strong>Preview URL with inProcessWebsite (CLI)</strong></p>
<p><strong><a href="https://github.com/episerver/content-js-sdk/pull/351">CMS-53120, PR #351</a></strong></p>
</td>
<td style="border-style: solid; border-width: 1px; text-align: left; vertical-align: top; padding: 1px;">
<p>Preview URLs didn't resolve correctly when using <strong>inProcessWebsite</strong></p>
</td>
<td style="border-style: solid; border-width: 1px; text-align: left; vertical-align: top; padding: 1px;">
<p>URL resolution logic fixed</p>
</td>
</tr>
</tbody>
</table>
<p> </p>
<hr />
<h2>How to Upgrade</h2>
<pre class="code-block"><code class="language-bash"># Upgrade the SDK
npm install @optimizely/cms-sdk@2.1.0
# Upgrade the CLI
npm install -D @optimizely/cms-cli@2.1.0</code></pre>
<p>There are no breaking changes in this release. Your existing <strong>contentType()</strong> schemas, registry configurations, and React component mappings continue to work without modification.</p>
<hr />
<h2>Full Changelog</h2>
<ul class="tight">
<li>
<p><a href="https://github.com/episerver/content-js-sdk/releases/tag/%40optimizely%2Fcms-sdk%402.1.0"><strong>@optimizely/cms-sdk@2.1.0</strong></a></p>
</li>
<li>
<p><a href="https://github.com/episerver/content-js-sdk/releases/tag/%40optimizely%2Fcms-cli%402.1.0"><strong>@optimizely/cms-cli@2.1.0</strong></a></p>
</li>
</ul>
<p> </p>
<p><strong><em class="far4bl _667h42">This post is a community-authored summary based on the <a class="_667h42 _1l4j4nad _1c9dtv3 _1by2b93 _1140xq1 _667h42" href="https://github.com/episerver/content-js-sdk/releases/tag/%40optimizely%2Fcms-sdk%402.1.0">official v2.1.0 release notes</a>. For authoritative guidance, always refer to the official Optimizely documentation.</em></strong></p>2026-07-08T03:20:06.0000000ZBlog postExploring Asset Lifecycle Management Approaches for Bynder and Optimizely SaaS CMS<p><span class="far4bl _667h42">Note: This is Part 3 of our Bynder integration series. For setup and filtering prerequisites, see <a class="_667h42 _1l4j4nac _1c9dtv3 _1by2b93 _1140xq1 _667h42" href="/link/4f215cd334254dfcbc121d5f4e20edd6.aspx">Part 1</a> and <a class="_667h42 _1l4j4nac _1c9dtv3 _1by2b93 _1140xq1 _667h42" href="/link/30275ac47c4843148eeda8b7d6ed282a.aspx">Part 2</a>.</span></p>
<h2><strong>Introduction</strong></h2>
<p>In my previous article, I explored approaches for controlling asset ingestion from Bynder into Optimizely SaaS CMS through metadata-based filtering.</p>
<p>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.</p>
<p>Once assets have been synchronized, a different set of challenges begins to emerge:</p>
<ul>
<li>What happens when an asset's metadata changes after synchronization?</li>
<li>How should previously synchronized assets be handled when they no longer meet business rules?</li>
<li>How can organizations govern assets across Development, Staging, and Production environments?</li>
<li>How can teams safely determine whether an asset is still being used before removing it?</li>
<li>When does it make sense to extend an existing integration versus building a completely custom connector?</li>
</ul>
<p>These questions gradually shift the conversation from asset synchronization to asset lifecycle management.</p>
<p>This article explores some architectural considerations and potential approaches that may help address those challenges.</p>
<hr />
<h2><strong>The Asset Lifecycle Challenge</strong></h2>
<p>Synchronization is rarely a one-time event. Assets constantly evolve throughout their lifetime. <br />A typical lifecycle might look something like this:</p>
<div class="___77lcry0 f10pi13n">
<div class="___1hewfwb f10pi13n f7oukh6 f5p0z4x">
<div class="fui-FluentProvider codeBlock-7100fui-FluentProviderr6av ___1jk74h0 fzk5nv6 f6n0el9 f7x6x6c f1a9mlr7 flj889f f13g0yyb ffzn0d2">
<div class="scriptor-component-code-block NhtKn7PZLzk24rduw4FJVQ== scriptor-codeblock-virtualized">
<div class="UkrLoQNicnNa5hsNIz3QLw== SpjJXGAclwYtfY+SokpSTg== ZF-Q2MvOY8aWSpGWW7iKRQ== anUhzybDvd7+8CBdKK7ukg==">
<div class="AHKpBuU8t+rAbDNImLlOHQ== lHY5JJVFnU8S-jx-OGwJkg== IUtI8YkF5Dl2LTlcjMDTwg==">
<div class="___149cboo fssjx5q f11d9hfk fj2zk3l fmyxm6j f1ldmben f1rkeeuc">
<div class="___svqwvq0 fssjx5q f11d9hfk fj2zk3l f1ldmben fzdgvog f19k5jia fzv833z f1r8x5cv f1687457 fe71wc6 f1wco4xj f103jgab f12fk6ok f4j985t fv86erk f1b4dd42 f1qwtq3x f13gvrpj f132if0v f1vblqk2 fkxsc7s f18j3zqo f1386a7m f1w3nze9 f14pe09c f4skf1h f1lq0dgc f1jgwha3 fbf5vau fc8703c">
<div class="___ysqij10 fonrc96 f1d3un5n fdk4ulh f1cijgmw fzb3wgo fssjx5q f11d9hfk fee5icb fr1uqzy">
<div class="___sv9ola0 fj2zk3l f1f4vkoj scriptor-instance-681">
<div class="scriptor-canvas scriptor-styled-scrollbar focus-container">
<div class="scriptor-pageContainer">
<div class="scriptor-pageFrame scriptor-firstPage scriptor-webView scriptor-content-visibility-auto">
<div class="scriptor-code-editor scriptor-code-wrap-on scriptor-pageBody scriptor-webViewPage">
<div class="scriptor-paragraph"><strong><span class="scriptor-textRun scriptor-inline">Asset Created > </span><span class="scriptor-textRun scriptor-inline">Asset Synchronized > </span><span class="scriptor-textRun scriptor-inline">Asset Referenced by Content > Asset </span><span class="scriptor-textRun scriptor-inline">Metadata Updated > </span><span class="scriptor-textRun scriptor-inline">Visibility Rules Changed > </span><span class="scriptor-textRun scriptor-inline">Environment Assignment Changed > </span><span class="scriptor-textRun scriptor-inline">Asset No Longer Valid</span></strong></div>
<div class="scriptor-paragraph"> </div>
<div class="scriptor-paragraph">Most DAM integrations handle the first half of this journey very well.</div>
<div class="scriptor-paragraph">The second half is often where complexity starts to appear.</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p>For example:</p>
<ul>
<li>An image may no longer belong to a target environment.</li>
<li>An image may become hidden through metadata changes.</li>
<li>An image may remain inside Optimizely despite no longer being available within Bynder.</li>
<li>An image may still be actively referenced by content authors even though business rules indicate it should be removed.</li>
</ul>
<p>These scenarios introduce governance challenges that extend well beyond initial synchronization.</p>
<hr />
<h2><strong>Orphaned Assets</strong></h2>
<p>One scenario that stood out during evaluation was the possibility of orphaned assets.</p>
<p>Consider the following sequence:</p>
<div class="___77lcry0 f10pi13n">
<div class="___1hewfwb f10pi13n f7oukh6 f5p0z4x">
<div class="fui-FluentProvider codeBlock-6816fui-FluentProviderr6b8 ___1jk74h0 fzk5nv6 f6n0el9 f7x6x6c f1a9mlr7 flj889f f13g0yyb ffzn0d2">
<div class="scriptor-component-code-block NhtKn7PZLzk24rduw4FJVQ== scriptor-codeblock-virtualized">
<div class="UkrLoQNicnNa5hsNIz3QLw== SpjJXGAclwYtfY+SokpSTg== ZF-Q2MvOY8aWSpGWW7iKRQ== anUhzybDvd7+8CBdKK7ukg==">
<div class="AHKpBuU8t+rAbDNImLlOHQ== lHY5JJVFnU8S-jx-OGwJkg== IUtI8YkF5Dl2LTlcjMDTwg==">
<div class="___149cboo fssjx5q f11d9hfk fj2zk3l fmyxm6j f1ldmben f1rkeeuc">
<div class="___svqwvq0 fssjx5q f11d9hfk fj2zk3l f1ldmben fzdgvog f19k5jia fzv833z f1r8x5cv f1687457 fe71wc6 f1wco4xj f103jgab f12fk6ok f4j985t fv86erk f1b4dd42 f1qwtq3x f13gvrpj f132if0v f1vblqk2 fkxsc7s f18j3zqo f1386a7m f1w3nze9 f14pe09c f4skf1h f1lq0dgc f1jgwha3 fbf5vau fc8703c">
<div class="___ysqij10 fonrc96 f1d3un5n fdk4ulh f1cijgmw fzb3wgo fssjx5q f11d9hfk fee5icb fr1uqzy">
<div class="___sv9ola0 fj2zk3l f1f4vkoj scriptor-instance-682">
<div class="scriptor-canvas scriptor-styled-scrollbar focus-container">
<div class="scriptor-pageContainer">
<div class="scriptor-pageFrame scriptor-firstPage scriptor-webView scriptor-content-visibility-auto">
<div class="scriptor-code-editor scriptor-code-wrap-on scriptor-pageBody scriptor-webViewPage">
<div class="scriptor-paragraph"><strong><span class="scriptor-textRun scriptor-inline">Asset synchronized > </span><span class="scriptor-textRun scriptor-inline">Metadata changes > </span><span class="scriptor-textRun scriptor-inline">Asset moves out of scope > </span><span class="scriptor-textRun scriptor-inline">Synchronization account </span><span class="scriptor-textRun scriptor-inline">can no longer access asset > </span><span class="scriptor-textRun scriptor-inline">Asset remains in Optimizely</span></strong></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p>From the perspective of the synchronization process, the asset has effectively disappeared.</p>
<p>The integration can no longer retrieve information about the asset.</p>
<p>However, the existing record may continue to exist inside Optimizely.</p>
<p>Over time, these records could accumulate, creating a divergence between the source DAM and the target CMS repository.</p>
<p>While this may not create an immediate problem, organizations with large asset libraries may eventually start asking:</p>
<ul>
<li>Which assets are still valid?</li>
<li>Which assets should still exist?</li>
<li>Which assets are no longer governed by the current synchronization rules?</li>
</ul>
<p>These questions become increasingly important as repositories grow.</p>
<hr />
<h2><strong>Environment Governance</strong></h2>
<p>Another consideration involves environment ownership.</p>
<p>Most enterprise implementations maintain separate environments:</p>
<div class="___77lcry0 f10pi13n">
<div class="___1hewfwb f10pi13n f7oukh6 f5p0z4x">
<div class="fui-FluentProvider codeBlock-1565fui-FluentProviderr6bh ___1jk74h0 fzk5nv6 f6n0el9 f7x6x6c f1a9mlr7 flj889f f13g0yyb ffzn0d2">
<div class="scriptor-component-code-block NhtKn7PZLzk24rduw4FJVQ== scriptor-codeblock-virtualized">
<div class="UkrLoQNicnNa5hsNIz3QLw== SpjJXGAclwYtfY+SokpSTg== ZF-Q2MvOY8aWSpGWW7iKRQ== anUhzybDvd7+8CBdKK7ukg==">
<div class="AHKpBuU8t+rAbDNImLlOHQ== lHY5JJVFnU8S-jx-OGwJkg== IUtI8YkF5Dl2LTlcjMDTwg==">
<div class="___149cboo fssjx5q f11d9hfk fj2zk3l fmyxm6j f1ldmben f1rkeeuc">
<div class="___svqwvq0 fssjx5q f11d9hfk fj2zk3l f1ldmben fzdgvog f19k5jia fzv833z f1r8x5cv f1687457 fe71wc6 f1wco4xj f103jgab f12fk6ok f4j985t fv86erk f1b4dd42 f1qwtq3x f13gvrpj f132if0v f1vblqk2 fkxsc7s f18j3zqo f1386a7m f1w3nze9 f14pe09c f4skf1h f1lq0dgc f1jgwha3 fbf5vau fc8703c">
<div class="___ysqij10 fonrc96 f1d3un5n fdk4ulh f1cijgmw fzb3wgo fssjx5q f11d9hfk fee5icb fr1uqzy">
<div class="___sv9ola0 fj2zk3l f1f4vkoj scriptor-instance-683">
<div class="scriptor-canvas scriptor-styled-scrollbar focus-container">
<div class="scriptor-pageContainer">
<div class="scriptor-pageFrame scriptor-firstPage scriptor-webView scriptor-content-visibility-auto">
<div class="scriptor-code-editor scriptor-code-wrap-on scriptor-pageBody scriptor-webViewPage">
<div class="scriptor-paragraph">
<ul>
<li><span class="scriptor-textRun scriptor-inline">Development</span></li>
<li>Staging</li>
<li>Production</li>
</ul>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p>However, DAM platforms are often centrally managed.</p>
<p>A common scenario looks something like this:</p>
<p><img style="border-width: 1px; border-style: solid;" src="/link/4c2f0e70051d44828bb2530d6be7e584.aspx" alt="" width="722" height="482" /></p>
<p>Without additional controls, all environments may receive identical assets.</p>
<p>This can introduce several concerns:</p>
<ul>
<li>Increased storage consumption</li>
<li>Cluttered non-production environments</li>
<li>Difficult testing scenarios</li>
<li>Confusion around environment-specific assets</li>
</ul>
<h3><strong>Suggested Environment Metadata Approach</strong></h3>
<p>One possible approach is introducing an additional metadata property or use tags inside Bynder.</p>
<p>Example:</p>
<p><span class="scriptor-textRun scriptor-inline">"website-environment" metadata property with p</span>ossible values:</p>
<div class="___77lcry0 f10pi13n">
<div class="___1hewfwb f10pi13n f7oukh6 f5p0z4x">
<div class="fui-FluentProvider codeBlock-9217fui-FluentProviderr6cc ___1jk74h0 fzk5nv6 f6n0el9 f7x6x6c f1a9mlr7 flj889f f13g0yyb ffzn0d2">
<div class="scriptor-component-code-block NhtKn7PZLzk24rduw4FJVQ== scriptor-codeblock-virtualized">
<div class="UkrLoQNicnNa5hsNIz3QLw== SpjJXGAclwYtfY+SokpSTg== ZF-Q2MvOY8aWSpGWW7iKRQ== anUhzybDvd7+8CBdKK7ukg==">
<div class="AHKpBuU8t+rAbDNImLlOHQ== lHY5JJVFnU8S-jx-OGwJkg== IUtI8YkF5Dl2LTlcjMDTwg==">
<div class="___149cboo fssjx5q f11d9hfk fj2zk3l fmyxm6j f1ldmben f1rkeeuc">
<div class="___svqwvq0 fssjx5q f11d9hfk fj2zk3l f1ldmben fzdgvog f19k5jia fzv833z f1r8x5cv f1687457 fe71wc6 f1wco4xj f103jgab f12fk6ok f4j985t fv86erk f1b4dd42 f1qwtq3x f13gvrpj f132if0v f1vblqk2 fkxsc7s f18j3zqo f1386a7m f1w3nze9 f14pe09c f4skf1h f1lq0dgc f1jgwha3 fbf5vau fc8703c">
<div class="___ysqij10 fonrc96 f1d3un5n fdk4ulh f1cijgmw fzb3wgo fssjx5q f11d9hfk fee5icb fr1uqzy">
<div class="___sv9ola0 fj2zk3l f1f4vkoj scriptor-instance-686">
<div class="scriptor-canvas scriptor-styled-scrollbar focus-container">
<div class="scriptor-pageContainer">
<div class="scriptor-pageFrame scriptor-firstPage scriptor-webView scriptor-content-visibility-auto">
<div class="scriptor-code-editor scriptor-code-wrap-on scriptor-pageBody scriptor-webViewPage">
<ul>
<li class="scriptor-paragraph"><span class="scriptor-textRun scriptor-inline">Development</span></li>
<li class="scriptor-paragraph"><span class="scriptor-textRun scriptor-inline">Staging</span></li>
<li class="scriptor-paragraph"><span class="scriptor-textRun scriptor-inline">Production</span></li>
</ul>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p>This metadata could travel alongside normal asset synchronization and provide additional governance information to downstream systems.</p>
<h4><strong>Suggested Visibility Configuration</strong></h4>
<p>Unlike visibility-based filtering rules, this property/tags does not need to setup separate profiles/users and any explicit filtering rules.</p>
<p>The goal is not to hide assets. The goal is to communicate intent.</p>
<div class="___77lcry0 f10pi13n">
<div class="___1hewfwb f10pi13n f7oukh6 f5p0z4x">
<div class="fui-FluentProvider codeBlock-2862fui-FluentProviderr6cu ___1jk74h0 fzk5nv6 f6n0el9 f7x6x6c f1a9mlr7 flj889f f13g0yyb ffzn0d2">
<div class="scriptor-component-code-block NhtKn7PZLzk24rduw4FJVQ== scriptor-codeblock-virtualized">
<div class="UkrLoQNicnNa5hsNIz3QLw== SpjJXGAclwYtfY+SokpSTg== ZF-Q2MvOY8aWSpGWW7iKRQ== anUhzybDvd7+8CBdKK7ukg==">
<div class="AHKpBuU8t+rAbDNImLlOHQ== lHY5JJVFnU8S-jx-OGwJkg== IUtI8YkF5Dl2LTlcjMDTwg==">
<div class="___149cboo fssjx5q f11d9hfk fj2zk3l fmyxm6j f1ldmben f1rkeeuc">
<div class="___svqwvq0 fssjx5q f11d9hfk fj2zk3l f1ldmben fzdgvog f19k5jia fzv833z f1r8x5cv f1687457 fe71wc6 f1wco4xj f103jgab f12fk6ok f4j985t fv86erk f1b4dd42 f1qwtq3x f13gvrpj f132if0v f1vblqk2 fkxsc7s f18j3zqo f1386a7m f1w3nze9 f14pe09c f4skf1h f1lq0dgc f1jgwha3 fbf5vau fc8703c">
<div class="___ysqij10 fonrc96 f1d3un5n fdk4ulh f1cijgmw fzb3wgo fssjx5q f11d9hfk fee5icb fr1uqzy">
<div class="___sv9ola0 fj2zk3l f1f4vkoj scriptor-instance-688">
<div class="scriptor-canvas scriptor-styled-scrollbar focus-container">
<div class="scriptor-pageContainer">
<div class="scriptor-pageFrame scriptor-firstPage scriptor-webView scriptor-content-visibility-auto">
<div class="scriptor-code-editor scriptor-code-wrap-on scriptor-pageBody scriptor-webViewPage">
<div class="scriptor-paragraph">For example: If an asset that is tagged for development environment received in production environement then that asset should be treated as out of scope and vice versa for other environments.</div>
<div class="scriptor-paragraph"> </div>
<div class="scriptor-paragraph">Asset target Environment: Development</div>
<div class="scriptor-paragraph">Asset Synced in: Production</div>
<div class="scriptor-paragraph">Result: Potentially Out of Scope</div>
</div>
<div class="scriptor-highlightWrapper"> </div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<div class="scriptor-paragraph">
<div>With this approach, a centralized DAM repository can continue serving multiple environments while still supporting environment-specific governance decisions.</div>
</div>
</div>
</div>
</div>
</div>
<hr />
<h2><strong>Why Environment Metadata May Be Valuable</strong></h2>
<p>Without environment metadata, every environment receives same assets.</p>
<p>With environment metadata, environment validation processes can be setup to stop storing assets those are not required in the environment.</p>
<p>This approach may provide a lightweight governance layer without introducing separate DAM repositories, separate taxonomies, or separate synchronization configurations.</p>
<hr />
<h2><strong>Architectural Note</strong></h2>
<p>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.</p>
<p>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.</p>
<p>The intent of this article is to explore a potential governance pattern and discuss its trade-offs rather than present a proven production architecture.</p>
<hr />
<h2><strong>Exploring an Event-Driven Governance Model</strong></h2>
<p>One approach that appears interesting from an architectural perspective is introducing a webhook-driven governance workflow.</p>
<p>For simplicity, this article assumes the webhook endpoint is deployed inside the frontend nextjs application.</p>
<p>In practice, the webhook could be hosted anywhere:</p>
<ul>
<li>Next.js API Route</li>
<li>Azure Function</li>
<li>AWS Lambda</li>
<li>Google Cloud Function</li>
<li>Dedicated Middleware Service</li>
<li>Integration Platform</li>
</ul>
<p>The location itself is less important than the validation process being executed.</p>
<p>At a high level:</p>
<div class="___77lcry0 f10pi13n">
<div class="___1hewfwb f10pi13n f7oukh6 f5p0z4x">
<div class="fui-FluentProvider codeBlock-1675fui-FluentProviderr6dp ___1jk74h0 fzk5nv6 f6n0el9 f7x6x6c f1a9mlr7 flj889f f13g0yyb ffzn0d2">
<div class="scriptor-component-code-block NhtKn7PZLzk24rduw4FJVQ== scriptor-codeblock-virtualized">
<div class="UkrLoQNicnNa5hsNIz3QLw== SpjJXGAclwYtfY+SokpSTg== ZF-Q2MvOY8aWSpGWW7iKRQ== anUhzybDvd7+8CBdKK7ukg==">
<div class="AHKpBuU8t+rAbDNImLlOHQ== lHY5JJVFnU8S-jx-OGwJkg== IUtI8YkF5Dl2LTlcjMDTwg==">
<div class="___149cboo fssjx5q f11d9hfk fj2zk3l fmyxm6j f1ldmben f1rkeeuc">
<div class="___svqwvq0 fssjx5q f11d9hfk fj2zk3l f1ldmben fzdgvog f19k5jia fzv833z f1r8x5cv f1687457 fe71wc6 f1wco4xj f103jgab f12fk6ok f4j985t fv86erk f1b4dd42 f1qwtq3x f13gvrpj f132if0v f1vblqk2 fkxsc7s f18j3zqo f1386a7m f1w3nze9 f14pe09c f4skf1h f1lq0dgc f1jgwha3 fbf5vau fc8703c">
<div class="___ysqij10 fonrc96 f1d3un5n fdk4ulh f1cijgmw fzb3wgo fssjx5q f11d9hfk fee5icb fr1uqzy">
<div class="___sv9ola0 fj2zk3l f1f4vkoj scriptor-instance-691">
<div class="scriptor-canvas scriptor-styled-scrollbar focus-container">
<div class="scriptor-pageContainer">
<div class="scriptor-pageFrame scriptor-firstPage scriptor-webView scriptor-content-visibility-auto">
<div class="scriptor-code-editor scriptor-code-wrap-on scriptor-pageBody scriptor-webViewPage">
<div class="scriptor-paragraph"><strong><span class="scriptor-textRun scriptor-inline">Bynder Calls Webhook > </span><span class="scriptor-textRun scriptor-inline">Webhook Receives event > </span><span class="scriptor-textRun scriptor-inline">Validation Logic > Asset remains or Deleted</span></strong></div>
<div class="scriptor-paragraph"> </div>
<div class="scriptor-paragraph"><strong><span class="scriptor-textRun scriptor-inline"><img style="border-width: 1px; border-style: solid;" src="/link/6924927432474ebbbf0173898da1d109.aspx?1783236197175" width="575" height="699" /></span></strong></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<div class="___77lcry0 f10pi13n">
<div class="___1hewfwb f10pi13n f7oukh6 f5p0z4x">
<div class="fui-FluentProvider codeBlock-1955fui-FluentProviderr6e2 ___1jk74h0 fzk5nv6 f6n0el9 f7x6x6c f1a9mlr7 flj889f f13g0yyb ffzn0d2">
<div class="scriptor-component-code-block NhtKn7PZLzk24rduw4FJVQ== scriptor-codeblock-virtualized">
<div class="UkrLoQNicnNa5hsNIz3QLw== SpjJXGAclwYtfY+SokpSTg== ZF-Q2MvOY8aWSpGWW7iKRQ== anUhzybDvd7+8CBdKK7ukg==">
<div class="AHKpBuU8t+rAbDNImLlOHQ== lHY5JJVFnU8S-jx-OGwJkg== IUtI8YkF5Dl2LTlcjMDTwg==">
<div class="___149cboo fssjx5q f11d9hfk fj2zk3l fmyxm6j f1ldmben f1rkeeuc">
<div class="___svqwvq0 fssjx5q f11d9hfk fj2zk3l f1ldmben fzdgvog f19k5jia fzv833z f1r8x5cv f1687457 fe71wc6 f1wco4xj f103jgab f12fk6ok f4j985t fv86erk f1b4dd42 f1qwtq3x f13gvrpj f132if0v f1vblqk2 fkxsc7s f18j3zqo f1386a7m f1w3nze9 f14pe09c f4skf1h f1lq0dgc f1jgwha3 fbf5vau fc8703c">
<div class="___ysqij10 fonrc96 f1d3un5n fdk4ulh f1cijgmw fzb3wgo fssjx5q f11d9hfk fee5icb fr1uqzy">
<div class="___sv9ola0 fj2zk3l f1f4vkoj scriptor-instance-692">
<div class="scriptor-canvas scriptor-styled-scrollbar focus-container">
<div class="scriptor-pageContainer">
<div class="scriptor-pageFrame scriptor-firstPage scriptor-webView scriptor-content-visibility-auto"> </div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<div class="scriptor-code-scroll-proxy">
<h2><strong>Three Gates</strong></h2>
</div>
</div>
</div>
</div>
</div>
<h3><strong>Gate 1: Visibility Validation</strong></h3>
<p>The first validation stage could determine whether the asset remains visible to the synchronization account.<br />Note: Use permanent token assigned for the synchronization account.</p>
<p>Conceptually:</p>
<div class="___77lcry0 f10pi13n">
<div class="___1hewfwb f10pi13n f7oukh6 f5p0z4x">
<div class="fui-FluentProvider codeBlock-2459fui-FluentProviderr6eb ___1jk74h0 fzk5nv6 f6n0el9 f7x6x6c f1a9mlr7 flj889f f13g0yyb ffzn0d2">
<div class="scriptor-component-code-block NhtKn7PZLzk24rduw4FJVQ== scriptor-codeblock-virtualized">
<div class="UkrLoQNicnNa5hsNIz3QLw== SpjJXGAclwYtfY+SokpSTg== ZF-Q2MvOY8aWSpGWW7iKRQ== anUhzybDvd7+8CBdKK7ukg==">
<div class="AHKpBuU8t+rAbDNImLlOHQ== lHY5JJVFnU8S-jx-OGwJkg== IUtI8YkF5Dl2LTlcjMDTwg==">
<div class="___149cboo fssjx5q f11d9hfk fj2zk3l fmyxm6j f1ldmben f1rkeeuc">
<div class="___svqwvq0 fssjx5q f11d9hfk fj2zk3l f1ldmben fzdgvog f19k5jia fzv833z f1r8x5cv f1687457 fe71wc6 f1wco4xj f103jgab f12fk6ok f4j985t fv86erk f1b4dd42 f1qwtq3x f13gvrpj f132if0v f1vblqk2 fkxsc7s f18j3zqo f1386a7m f1w3nze9 f14pe09c f4skf1h f1lq0dgc f1jgwha3 fbf5vau fc8703c">
<div class="___ysqij10 fonrc96 f1d3un5n fdk4ulh f1cijgmw fzb3wgo fssjx5q f11d9hfk fee5icb fr1uqzy">
<div class="___sv9ola0 fj2zk3l f1f4vkoj scriptor-instance-693">
<div class="scriptor-canvas scriptor-styled-scrollbar focus-container">
<div class="scriptor-pageContainer">
<div class="scriptor-pageFrame scriptor-firstPage scriptor-webView scriptor-content-visibility-auto">
<div class="scriptor-code-editor scriptor-code-wrap-on scriptor-pageBody scriptor-webViewPage">
<div class="scriptor-paragraph"><span class="scriptor-textRun scriptor-inline">Asset Updated > </span><span class="scriptor-textRun scriptor-inline">Retrieve Asset > </span><span class="scriptor-textRun scriptor-inline">Accessible > </span>Decision</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<div class="___77lcry0 f10pi13n">
<div class="___1hewfwb f10pi13n f7oukh6 f5p0z4x">
<div class="fui-FluentProvider codeBlock-5518fui-FluentProviderr6ek ___1jk74h0 fzk5nv6 f6n0el9 f7x6x6c f1a9mlr7 flj889f f13g0yyb ffzn0d2">
<div class="scriptor-component-code-block NhtKn7PZLzk24rduw4FJVQ== scriptor-codeblock-virtualized">
<div class="UkrLoQNicnNa5hsNIz3QLw== SpjJXGAclwYtfY+SokpSTg== ZF-Q2MvOY8aWSpGWW7iKRQ== anUhzybDvd7+8CBdKK7ukg==">
<div class="AHKpBuU8t+rAbDNImLlOHQ== lHY5JJVFnU8S-jx-OGwJkg== IUtI8YkF5Dl2LTlcjMDTwg==">
<div class="___149cboo fssjx5q f11d9hfk fj2zk3l fmyxm6j f1ldmben f1rkeeuc">
<div class="___svqwvq0 fssjx5q f11d9hfk fj2zk3l f1ldmben fzdgvog f19k5jia fzv833z f1r8x5cv f1687457 fe71wc6 f1wco4xj f103jgab f12fk6ok f4j985t fv86erk f1b4dd42 f1qwtq3x f13gvrpj f132if0v f1vblqk2 fkxsc7s f18j3zqo f1386a7m f1w3nze9 f14pe09c f4skf1h f1lq0dgc f1jgwha3 fbf5vau fc8703c">
<div class="___ysqij10 fonrc96 f1d3un5n fdk4ulh f1cijgmw fzb3wgo fssjx5q f11d9hfk fee5icb fr1uqzy">
<div class="___sv9ola0 fj2zk3l f1f4vkoj scriptor-instance-694">
<div class="scriptor-canvas scriptor-styled-scrollbar focus-container">
<div class="scriptor-pageContainer">
<div class="scriptor-pageFrame scriptor-firstPage scriptor-webView scriptor-content-visibility-auto">
<div class="scriptor-code-editor scriptor-code-wrap-on scriptor-pageBody scriptor-webViewPage">
<div class="scriptor-paragraph"><span class="scriptor-textRun scriptor-inline"> Decision > YES > </span><span class="scriptor-textRun scriptor-inline">Continue</span></div>
<div class="scriptor-paragraph"><span class="scriptor-textRun scriptor-inline"> Decision > NO > </span><span class="scriptor-textRun scriptor-inline">Potential Cleanup Candidate</span></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p>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.</p>
<hr />
<h3><strong>Gate 2: Environment Validation</strong></h3>
<p>The second validation stage could evaluate environmental ownership.</p>
<p>Example workflow:</p>
<div class="___77lcry0 f10pi13n">
<div class="___1hewfwb f10pi13n f7oukh6 f5p0z4x">
<div class="fui-FluentProvider codeBlock-5562fui-FluentProviderr6et ___1jk74h0 fzk5nv6 f6n0el9 f7x6x6c f1a9mlr7 flj889f f13g0yyb ffzn0d2">
<div class="scriptor-component-code-block NhtKn7PZLzk24rduw4FJVQ== scriptor-codeblock-virtualized">
<div class="UkrLoQNicnNa5hsNIz3QLw== SpjJXGAclwYtfY+SokpSTg== ZF-Q2MvOY8aWSpGWW7iKRQ== anUhzybDvd7+8CBdKK7ukg==">
<div class="AHKpBuU8t+rAbDNImLlOHQ== lHY5JJVFnU8S-jx-OGwJkg== IUtI8YkF5Dl2LTlcjMDTwg==">
<div class="___149cboo fssjx5q f11d9hfk fj2zk3l fmyxm6j f1ldmben f1rkeeuc">
<div class="___svqwvq0 fssjx5q f11d9hfk fj2zk3l f1ldmben fzdgvog f19k5jia fzv833z f1r8x5cv f1687457 fe71wc6 f1wco4xj f103jgab f12fk6ok f4j985t fv86erk f1b4dd42 f1qwtq3x f13gvrpj f132if0v f1vblqk2 fkxsc7s f18j3zqo f1386a7m f1w3nze9 f14pe09c f4skf1h f1lq0dgc f1jgwha3 fbf5vau fc8703c">
<div class="___ysqij10 fonrc96 f1d3un5n fdk4ulh f1cijgmw fzb3wgo fssjx5q f11d9hfk fee5icb fr1uqzy">
<div class="___sv9ola0 fj2zk3l f1f4vkoj scriptor-instance-695">
<div class="scriptor-canvas scriptor-styled-scrollbar focus-container">
<div class="scriptor-pageContainer">
<div class="scriptor-pageFrame scriptor-firstPage scriptor-webView scriptor-content-visibility-auto">
<div class="scriptor-code-editor scriptor-code-wrap-on scriptor-pageBody scriptor-webViewPage">
<div class="scriptor-paragraph"><span class="scriptor-textRun scriptor-inline">Asset Updated > </span><span class="scriptor-textRun scriptor-inline">Read website-environment > </span><span class="scriptor-textRun scriptor-inline">Compare Against </span><span class="scriptor-textRun scriptor-inline">Current Environment > </span>Decision:</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<div class="___77lcry0 f10pi13n">
<div class="___1hewfwb f10pi13n f7oukh6 f5p0z4x">
<div class="fui-FluentProvider codeBlock-2919fui-FluentProviderr6f6 ___1jk74h0 fzk5nv6 f6n0el9 f7x6x6c f1a9mlr7 flj889f f13g0yyb ffzn0d2">
<div class="scriptor-component-code-block NhtKn7PZLzk24rduw4FJVQ== scriptor-codeblock-virtualized">
<div class="CDXiecnD7ekDByb7Z+4oEA==">
<div class="r14iuplo fui-AriaLive__assertive">
<div class="scriptor-paragraph"><span class="scriptor-textRun scriptor-inline"> Decision > Match > </span><span class="scriptor-textRun scriptor-inline">Continue</span></div>
<div class="scriptor-paragraph"><span class="scriptor-textRun scriptor-inline"> Decision > No Match > </span><span class="scriptor-textRun scriptor-inline">Potential Cleanup Candidate</span></div>
</div>
</div>
</div>
</div>
</div>
</div>
<p>This allows governance decisions to be made without requiring separate DAM repositories.</p>
<p>An asset intended exclusively for Production could potentially be excluded from lower environments while remaining available in Production.</p>
<hr />
<h3><strong>Gate 3: Reference Validation</strong></h3>
<div class="_1l4j4na3 _667h42">Before any removal occurs, a critical question must be answered: <strong class="far4bl _1a0p899 _667h42">Is the asset still being used?</strong></div>
<div class="_1l4j4na3 _667h42">Optimizely Graph does not currently expose a built-in reverse-reference lookup operator. This means there is no single, generic query to answer "which content items reference this asset?" without knowledge of the content model.</div>
<div class="_1l4j4na3 _667h42"> </div>
<div class="_1l4j4na3 _667h42"><strong class="far4bl _1a0p899 _667h42">Possible implementation approaches include:</strong></div>
<ol class="_667h42 _1l4j4na7">
<li class="_667h42 _1l4j4na2">
<div class="_1l4j4na3 _667h42"><strong class="far4bl _1a0p899 _667h42">Full-text search</strong> — Query <code class="_667h42 _1l4j4na5">Content</code> using <code class="_667h42 _1l4j4na5">_fulltext: { match: "asset-id" }</code> to search across all indexed content. Quick but imprecise — depends on how asset IDs are indexed.</div>
</li>
<li class="_667h42 _1l4j4na2">
<div class="_1l4j4na3 _667h42"><strong class="far4bl _1a0p899 _667h42">Schema introspection + targeted queries</strong> — Use GraphQL introspection to discover all content types with reference-type fields, then query each one. More thorough but requires automation to be practical.</div>
</li>
<li class="_667h42 _1l4j4na2">
<div class="_1l4j4na3 _667h42"><strong class="far4bl _1a0p899 _667h42">Content Management API enumeration</strong> — Use the CMS REST API to walk content and check references programmatically.</div>
</li>
</ol>
<div class="_1l4j4na3 _667h42">The right approach depends on your content model complexity, performance requirements, and how frequently this validation runs. <strong class="far4bl _1a0p899 _667h42">This gate will likely require a custom implementation tailored to your environment.</strong></div>
<div class="_1l4j4na3 _667h42"> </div>
<hr />
<h3><strong>Deleting Assets from Optimizely</strong></h3>
<p>Once an asset has been evaluated, a governance process may decide that removal should occur.</p>
<p>Important questions include:</p>
<ul>
<li>Is the asset still visible?</li>
<li>Is the asset assigned to the current environment?</li>
<li>Is the asset actively referenced?</li>
<li>Should the asset remain synchronized?</li>
</ul>
<p>If all validation checks indicate removal is appropriate, a deletion request could be submitted through the Content Management API.</p>
<p>An important distinction exists between: <span class="scriptor-textRun scriptor-inline">Soft Delete vs </span><span class="scriptor-textRun scriptor-inline">Hard Delete</span></p>
<p>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.</p>
<div class="___77lcry0 f10pi13n">
<div class="___1hewfwb f10pi13n f7oukh6 f5p0z4x">
<div class="fui-FluentProvider codeBlock-9961fui-FluentProviderr6gs ___1jk74h0 fzk5nv6 f6n0el9 f7x6x6c f1a9mlr7 flj889f f13g0yyb ffzn0d2">
<div class="scriptor-component-code-block NhtKn7PZLzk24rduw4FJVQ== scriptor-codeblock-virtualized">
<div class="CDXiecnD7ekDByb7Z+4oEA==">
<div class="r14iuplo fui-AriaLive__assertive">
<table style="border-collapse: collapse; width: 100.013%; margin-left: 0px; border-width: 1px; border-style: solid; margin-right: auto;">
<tbody>
<tr>
<td style="width: 10.9517%; text-align: left; vertical-align: top; border-style: solid; border-width: 1px;"><strong>Url & Headers</strong></td>
<td style="width: 89.0357%; text-align: left; vertical-align: top; border-style: solid; border-width: 1px;">
<div class="_47QlA7XYWbfK2INfVvTUjg==">
<div class="iVmNpJv5Hu1Eu0ev0L3Ffg==">
<div class="KU8Z3uOm5OU11Ica53+OVA==">
<div class="fui-Overflow Ye6tJij6H1xMCTdS6F25rA== ___s5d2bt0 f3x039c facid5">
<div class="vCHKFE0-MqMN20DBXhx6Ow==">
<div class="fui-Badge r1p3wql8 _9liocQIfHYrfQrOa5IZ50A== ___engtnk0 f1soahph fyk0x7v f17ad7pc f1evqen2 f70w86f fmfhf0j f1ar0y7c f1fzzbuc f176ju0o"> </div>
</div>
</div>
</div>
</div>
</div>
POST /api/content/v2/data?id=bynd HTTP/1.1<br />Host: cg.optimizely.com<br />Content-Type: application/x-ndjson<br />Authorization: Basic V25KQmNtUlpSNTFYaDJuSmE1UWV5eEkwWW...[Your_Base64_Encoded_Credentials]<br />
<div class="UkrLoQNicnNa5hsNIz3QLw== SpjJXGAclwYtfY+SokpSTg== ZF-Q2MvOY8aWSpGWW7iKRQ== anUhzybDvd7+8CBdKK7ukg==">
<div class="AHKpBuU8t+rAbDNImLlOHQ== lHY5JJVFnU8S-jx-OGwJkg== IUtI8YkF5Dl2LTlcjMDTwg==">
<div class="___149cboo fssjx5q f11d9hfk fj2zk3l fmyxm6j f1ldmben f1rkeeuc">
<div class="___svqwvq0 fssjx5q f11d9hfk fj2zk3l f1ldmben fzdgvog f19k5jia fzv833z f1r8x5cv f1687457 fe71wc6 f1wco4xj f103jgab f12fk6ok f4j985t fv86erk f1b4dd42 f1qwtq3x f13gvrpj f132if0v f1vblqk2 fkxsc7s f18j3zqo f1386a7m f1w3nze9 f14pe09c f4skf1h f1lq0dgc f1jgwha3 fbf5vau fc8703c">
<div class="___ysqij10 fonrc96 f1d3un5n fdk4ulh f1cijgmw fzb3wgo fssjx5q f11d9hfk fee5icb fr1uqzy">
<div class="___sv9ola0 fj2zk3l f1f4vkoj scriptor-instance-702">
<div class="scriptor-canvas scriptor-styled-scrollbar focus-container">
<div class="scriptor-pageContainer">
<div class="scriptor-pageFrame scriptor-firstPage scriptor-webView scriptor-content-visibility-auto">
<div class="scriptor-code-editor scriptor-code-wrap-on scriptor-pageBody scriptor-webViewPage">
<div class="scriptor-paragraph"> </div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</td>
</tr>
<tr>
<td style="width: 10.9517%; text-align: left; vertical-align: top; border-style: solid; border-width: 1px;"><strong>Body</strong></td>
<td style="width: 89.0357%; text-align: left; vertical-align: top; border-style: solid; border-width: 1px;">{"delete":{"_id":"bynder-asset-guid-12345","language_routing":"en"}}<br />{}</td>
</tr>
<tr>
<td style="width: 10.9517%; text-align: left; vertical-align: top; border-style: solid; border-width: 1px;"><strong>Response</strong></td>
<td style="width: 89.0357%; text-align: left; vertical-align: top; border-style: solid; border-width: 1px;">{<br /> "status": "success",<br /> "total_records_processed": 1,<br /> "deleted": 1,<br /> "errors": [],<br /> "took": 42<br />}</td>
</tr>
</tbody>
</table>
</div>
</div>
<div class="_47QlA7XYWbfK2INfVvTUjg==">
<div class="iVmNpJv5Hu1Eu0ev0L3Ffg=="> </div>
</div>
<div class="UkrLoQNicnNa5hsNIz3QLw== SpjJXGAclwYtfY+SokpSTg== ZF-Q2MvOY8aWSpGWW7iKRQ== anUhzybDvd7+8CBdKK7ukg==">
<div class="AHKpBuU8t+rAbDNImLlOHQ== lHY5JJVFnU8S-jx-OGwJkg== IUtI8YkF5Dl2LTlcjMDTwg==">
<div class="___149cboo fssjx5q f11d9hfk fj2zk3l fmyxm6j f1ldmben f1rkeeuc">
<div class="___svqwvq0 fssjx5q f11d9hfk fj2zk3l f1ldmben fzdgvog f19k5jia fzv833z f1r8x5cv f1687457 fe71wc6 f1wco4xj f103jgab f12fk6ok f4j985t fv86erk f1b4dd42 f1qwtq3x f13gvrpj f132if0v f1vblqk2 fkxsc7s f18j3zqo f1386a7m f1w3nze9 f14pe09c f4skf1h f1lq0dgc f1jgwha3 fbf5vau fc8703c">
<div class="___ysqij10 fonrc96 f1d3un5n fdk4ulh f1cijgmw fzb3wgo fssjx5q f11d9hfk fee5icb fr1uqzy">
<div class="___sv9ola0 fj2zk3l f1f4vkoj scriptor-instance-702">
<div class="scriptor-canvas scriptor-styled-scrollbar focus-container"> </div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p>This would permanently remove the asset rather than transferring it into a recycle bin.</p>
<hr />
<h2><strong>Monitoring and Troubleshooting</strong></h2>
<p>Whenever automated deletion is introduced, observability becomes extremely important.</p>
<p>Questions that operations teams will eventually ask include:</p>
<div class="___77lcry0 f10pi13n">
<div class="___1hewfwb f10pi13n f7oukh6 f5p0z4x">
<div class="fui-FluentProvider codeBlock-868fui-FluentProviderr6h5 ___1jk74h0 fzk5nv6 f6n0el9 f7x6x6c f1a9mlr7 flj889f f13g0yyb ffzn0d2">
<div class="scriptor-component-code-block NhtKn7PZLzk24rduw4FJVQ== scriptor-codeblock-virtualized">
<div class="UkrLoQNicnNa5hsNIz3QLw== SpjJXGAclwYtfY+SokpSTg== ZF-Q2MvOY8aWSpGWW7iKRQ== anUhzybDvd7+8CBdKK7ukg==">
<div class="AHKpBuU8t+rAbDNImLlOHQ== lHY5JJVFnU8S-jx-OGwJkg== IUtI8YkF5Dl2LTlcjMDTwg==">
<div class="___149cboo fssjx5q f11d9hfk fj2zk3l fmyxm6j f1ldmben f1rkeeuc">
<div class="___svqwvq0 fssjx5q f11d9hfk fj2zk3l f1ldmben fzdgvog f19k5jia fzv833z f1r8x5cv f1687457 fe71wc6 f1wco4xj f103jgab f12fk6ok f4j985t fv86erk f1b4dd42 f1qwtq3x f13gvrpj f132if0v f1vblqk2 fkxsc7s f18j3zqo f1386a7m f1w3nze9 f14pe09c f4skf1h f1lq0dgc f1jgwha3 fbf5vau fc8703c">
<div class="___ysqij10 fonrc96 f1d3un5n fdk4ulh f1cijgmw fzb3wgo fssjx5q f11d9hfk fee5icb fr1uqzy">
<div class="___sv9ola0 fj2zk3l f1f4vkoj scriptor-instance-703">
<div class="scriptor-canvas scriptor-styled-scrollbar focus-container">
<div class="scriptor-pageContainer">
<div class="scriptor-pageFrame scriptor-firstPage scriptor-webView scriptor-content-visibility-auto">
<div class="scriptor-code-editor scriptor-code-wrap-on scriptor-pageBody scriptor-webViewPage">
<ol>
<li class="scriptor-paragraph"><span class="scriptor-textRun scriptor-inline">Was a delete triggered?</span></li>
<li class="scriptor-paragraph"><span class="scriptor-textRun scriptor-inline">Which rule triggered it?</span></li>
<li class="scriptor-paragraph"><span class="scriptor-textRun scriptor-inline">Which asset was deleted?</span></li>
<li class="scriptor-paragraph"><span class="scriptor-textRun scriptor-inline">When did it occur?</span></li>
<li class="scriptor-paragraph"><span class="scriptor-textRun scriptor-inline">What response was returned?</span></li>
</ol>
<div class="scriptor-paragraph"> </div>
<div class="scriptor-paragraph">A potential audit trail might capture:</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<ul>
<li>Asset identifier</li>
<li>Event timestamp</li>
<li>Validation results</li>
<li>Environment</li>
<li>API response</li>
<li>Deletion outcome</li>
</ul>
<h3><strong>Monitoring Deletion Activity</strong></h3>
<p>One area that would require validation during implementation is how deletion activity can be monitored within the platform.</p>
<p>A potential starting point would be reviewing:</p>
<ul>
<li>Search & Navigation portal logs</li>
<li>Graph activity logs</li>
<li>API diagnostics</li>
<li>Application telemetry</li>
<li>Hosting platform logs</li>
</ul>
<p>This would help determine whether delete operations are executing successfully and provide additional visibility during troubleshooting.</p>
<hr />
<h2><strong>Extending the Existing Integration vs Building a Custom Connector</strong></h2>
<p>A natural question that often emerges is:</p>
<ul>
<li>If lifecycle governance is required, should we simply build a custom connector?</li>
</ul>
<p>The answer depends on organizational priorities.</p>
<table style="border-collapse: collapse; width: 79.5271%; border-width: 1px; height: 368.425px; border-spacing: 5px; border-style: solid;">
<tbody>
<tr style="height: 57.625px;">
<td style="text-align: left; vertical-align: top; border-width: 1px; width: 50.4919%; padding: 1px; border-style: solid; height: 57.625px;">
<h4><strong>Option 1: Extend the Existing Integration</strong></h4>
</td>
<td style="text-align: left; vertical-align: top; border-width: 1px; width: 49.4881%; padding: 1px; border-style: solid; height: 57.625px;">
<h4><strong>Option 2: Build a Fully Custom Connector</strong></h4>
</td>
</tr>
<tr style="height: 310.8px;">
<td style="text-align: left; vertical-align: top; border-width: 1px; width: 50.4919%; padding: 1px; border-style: solid; height: 310.8px;">
<p><span class="scriptor-textRun scriptor-inline">Bynder > </span><span class="scriptor-textRun scriptor-inline">OOTB Connector > </span><span class="scriptor-textRun scriptor-inline">Optimizely </span><span class="scriptor-textRun scriptor-inline">+ Governance Layer</span></p>
<p>Advantages:</p>
<ul>
<li>Faster implementation</li>
<li>Lower maintenance overhead</li>
<li>Vendor-supported synchronization</li>
<li>Smaller operational footprint</li>
</ul>
<p>Potential limitations:</p>
<ul>
<li>Less control over synchronization internals</li>
<li>Dependency on platform capabilities</li>
</ul>
</td>
<td style="text-align: left; vertical-align: top; border-width: 1px; width: 49.4881%; padding: 1px; border-style: solid; height: 310.8px;">
<div class="___77lcry0 f10pi13n">
<div class="___1hewfwb f10pi13n f7oukh6 f5p0z4x">
<div class="fui-FluentProvider codeBlock-9357fui-FluentProviderr6hn ___1jk74h0 fzk5nv6 f6n0el9 f7x6x6c f1a9mlr7 flj889f f13g0yyb ffzn0d2">
<div class="scriptor-component-code-block NhtKn7PZLzk24rduw4FJVQ== scriptor-codeblock-virtualized">
<div class="UkrLoQNicnNa5hsNIz3QLw== SpjJXGAclwYtfY+SokpSTg== ZF-Q2MvOY8aWSpGWW7iKRQ== anUhzybDvd7+8CBdKK7ukg==">
<div class="AHKpBuU8t+rAbDNImLlOHQ== lHY5JJVFnU8S-jx-OGwJkg== IUtI8YkF5Dl2LTlcjMDTwg==">
<div class="___149cboo fssjx5q f11d9hfk fj2zk3l fmyxm6j f1ldmben f1rkeeuc">
<div class="___svqwvq0 fssjx5q f11d9hfk fj2zk3l f1ldmben fzdgvog f19k5jia fzv833z f1r8x5cv f1687457 fe71wc6 f1wco4xj f103jgab f12fk6ok f4j985t fv86erk f1b4dd42 f1qwtq3x f13gvrpj f132if0v f1vblqk2 fkxsc7s f18j3zqo f1386a7m f1w3nze9 f14pe09c f4skf1h f1lq0dgc f1jgwha3 fbf5vau fc8703c">
<div class="___ysqij10 fonrc96 f1d3un5n fdk4ulh f1cijgmw fzb3wgo fssjx5q f11d9hfk fee5icb fr1uqzy">
<div class="___sv9ola0 fj2zk3l f1f4vkoj scriptor-instance-705">
<div class="scriptor-canvas scriptor-styled-scrollbar focus-container">
<div class="scriptor-pageContainer">
<div class="scriptor-pageFrame scriptor-firstPage scriptor-webView scriptor-content-visibility-auto">
<div class="scriptor-code-editor scriptor-code-wrap-on scriptor-pageBody scriptor-webViewPage">
<div class="scriptor-paragraph"><span class="scriptor-textRun scriptor-inline">Bynder > </span><span class="scriptor-textRun scriptor-inline">Custom Connector > </span><span class="scriptor-textRun scriptor-inline">Optimizely</span></div>
<div class="scriptor-paragraph"> </div>
<div class="scriptor-paragraph">Advantages:</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<ul>
<li>Complete control</li>
<li>Custom business logic</li>
<li>Full synchronization ownership</li>
</ul>
<p>Potential considerations:</p>
<ul>
<li>Authentication management</li>
<li>Delta synchronization</li>
<li>Retry handling</li>
<li>Error recovery</li>
<li>Schema evolution</li>
<li>Long-term maintenance costs</li>
</ul>
</td>
</tr>
</tbody>
</table>
<div class="___77lcry0 f10pi13n">
<div class="___1hewfwb f10pi13n f7oukh6 f5p0z4x">
<div class="fui-FluentProvider codeBlock-3356fui-FluentProviderr6he ___1jk74h0 fzk5nv6 f6n0el9 f7x6x6c f1a9mlr7 flj889f f13g0yyb ffzn0d2">
<div class="scriptor-component-code-block NhtKn7PZLzk24rduw4FJVQ== scriptor-codeblock-virtualized">
<div class="UkrLoQNicnNa5hsNIz3QLw== SpjJXGAclwYtfY+SokpSTg== ZF-Q2MvOY8aWSpGWW7iKRQ== anUhzybDvd7+8CBdKK7ukg==">
<div class="AHKpBuU8t+rAbDNImLlOHQ== lHY5JJVFnU8S-jx-OGwJkg== IUtI8YkF5Dl2LTlcjMDTwg==">
<div class="___149cboo fssjx5q f11d9hfk fj2zk3l fmyxm6j f1ldmben f1rkeeuc">
<div class="___svqwvq0 fssjx5q f11d9hfk fj2zk3l f1ldmben fzdgvog f19k5jia fzv833z f1r8x5cv f1687457 fe71wc6 f1wco4xj f103jgab f12fk6ok f4j985t fv86erk f1b4dd42 f1qwtq3x f13gvrpj f132if0v f1vblqk2 fkxsc7s f18j3zqo f1386a7m f1w3nze9 f14pe09c f4skf1h f1lq0dgc f1jgwha3 fbf5vau fc8703c">
<div class="___ysqij10 fonrc96 f1d3un5n fdk4ulh f1cijgmw fzb3wgo fssjx5q f11d9hfk fee5icb fr1uqzy">
<div class="___sv9ola0 fj2zk3l f1f4vkoj scriptor-instance-704">
<div class="scriptor-canvas scriptor-styled-scrollbar focus-container">
<div class="scriptor-pageContainer">
<div class="scriptor-pageFrame scriptor-firstPage scriptor-webView scriptor-content-visibility-auto">
<div class="scriptor-code-editor scriptor-code-wrap-on scriptor-pageBody scriptor-webViewPage"> </div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p>For many organizations, extending an existing integration with additional governance capabilities may represent a more balanced approach than replacing the synchronization engine altogether.</p>
<hr />
<h2><strong>Assumptions and Validation Status</strong></h2>
<p>The approaches discussed throughout this article are based on architectural evaluation and platform capability analysis rather than a fully validated production implementation.</p>
<p>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:</p>
<ul>
<li>Bynder webhooks</li>
<li>Bynder permanent tokens</li>
<li>Optimizely Content Management /Graph APIs</li>
<li>Optimizely Graph reference lookups</li>
<li>Standard event-driven integration patterns</li>
</ul>
<p>However, several areas would benefit from additional validation before adoption within a production environment:</p>
<ul>
<li>Large-scale webhook processing behavior</li>
<li>API rate limiting and throttling characteristics</li>
<li>Long-running operational reliability</li>
<li>Deletion timing and synchronization race conditions</li>
<li>Monitoring and alerting strategies</li>
<li>Reconciliation requirements for lost events</li>
<li>Long-term maintenance implications</li>
</ul>
<p>As with any architectural pattern, organizations should conduct their own validation, performance testing, and operational reviews before implementing the approach within production workloads.</p>
<div><hr />
<h2><strong>Conclusion</strong></h2>
<p>Asset synchronization is only one stage in the lifecycle of an enterprise DAM integration.</p>
<p>As asset repositories grow, organizations may also need to consider how visibility changes, environment allocation, content relationships, and cleanup processes should be handled over time.</p>
<p>The approaches discussed in this article should be viewed as architectural considerations rather than implementation recommendations. While the proposed event-driven governance model appears technically feasible based on the capabilities provided by Bynder, Optimizely SaaS CMS, and Optimizely Graph, additional validation and testing would be required before considering it for production adoption.</p>
<p>Ultimately, long-term success is unlikely to depend solely on controlling what enters the system. It may also require thoughtful approaches to governing assets throughout their lifecycle—from synchronization and distribution through validation, retention, and eventual removal.</p>
<hr />
<h4 class="_1l4j4na1 _1qskm0h c8urk _1a0p899 _5hqrjx _667h42">📚 Bynder + Optimizely SaaS CMS Integration Series</h4>
<div class="_1l4j4na3 _667h42"><em class="far4bl _667h42">This article is the final installment of a 3-part comprehensive architecture guide:</em></div>
<ul class="_667h42 _1l4j4na6">
<li class="_667h42 _1l4j4na2"><strong class="far4bl _1a0p899 _667h42">✅ Part 1: <a class="_667h42 _1l4j4nac _1c9dtv3 _1by2b93 _1140xq1 _667h42" href="/link/4f215cd334254dfcbc121d5f4e20edd6.aspx">Implementing the Connector — Lessons Learned</a></strong><br /><em class="far4bl _667h42">What metadata syncs, how URLs behave, and how to query/render assets in a Next.js frontend.<br /><br /></em></li>
<li class="_667h42 _1l4j4na2"><strong class="far4bl _1a0p899 _667h42">✅ Part 2: <a class="_667h42 _1l4j4nac _1c9dtv3 _1by2b93 _1140xq1 _667h42" href="/link/30275ac47c4843148eeda8b7d6ed282a.aspx">Planning & Filtering — Avoiding Asset Sprawl and Unnecessary Sync</a></strong><br /><em class="far4bl _667h42">How we achieved metadata-based sync filtering with zero custom code.<br /><br /></em></li>
<li class="_667h42 _1l4j4na2"><strong class="far4bl _1a0p899 _667h42">👉 Part 3: Exploring Asset Lifecycle Management & Three-Gate Governance</strong> <em class="far4bl _667h42">(You are here)</em><br /><em class="far4bl _667h42">A webhook-driven, three-gate model to handle asset updates, environments, and usage verification.</em></li>
</ul>
</div>2026-07-05T07:44:36.0000000ZBlog postPlanning Your Bynder DAM and Optimizely SaaS CMS Integration the Right Way: Avoiding Asset Sprawl and Unnecessary Synchronization<p class="MsoNormal"><span class="far4bl _667h42">Note: This is Part 2 of our Bynder integration series. If you missed the Part 1, check out "<a href="/link/4f215cd334254dfcbc121d5f4e20edd6.aspx">Implementing the Bynder DAM Connector with Optimizely SaaS CMS: Lessons Learned</a>".</span></p>
<p class="MsoNormal">In my previous article, I explored how the Bynder DAM Connector integrates with Optimizely SaaS CMS and how synchronized assets become available through Optimizely Graph and the CMS authoring experience.</p>
<p class="MsoNormal">This article focuses specifically on the Out-of-the-Box (OOTB) Bynder Connector available through Optimizely Connect Platform (OCP). The goal is to understand how much control can be achieved using standard Optimizely and Bynder capabilities before introducing custom integrations, middleware, or synchronization processes.</p>
<p class="MsoNormal">While the technical setup of the OOTB connector is relatively straightforward, I discovered that the most important decisions actually happen <em>before</em> the first synchronization is ever executed.</p>
<p class="MsoNormal">Many implementation teams focus on establishing the connection between Bynder and Optimizely. However, a more important architectural question is:</p>
<p class="MsoNormal"><strong>What assets should Optimizely be allowed to see in the first place?</strong></p>
<p class="MsoNormal">For organizations that use Bynder as a centralized Digital Asset Management platform, the answer has significant implications for governance, editor experience, operational overhead, and long-term scalability.</p>
<p class="MsoNormal">This article focuses on the planning and governance considerations that should be addressed before enabling the Bynder connector.</p>
<div class="MsoNormal" style="text-align: center;" align="center"><hr /></div>
<h3 class="MsoNormal"><strong>Understanding the Default Connector Behavior</strong></h3>
<p class="MsoNormal">The Out-of-the-Box (OOTB) Bynder connector synchronizes assets that are visible to the authenticated Bynder account.</p>
<p class="MsoNormal">In simple terms, the connector does not determine which assets should be synchronized. Bynder determines that by evaluating the permissions of the account used during the authorization process.</p>
<p class="MsoNormal">As a result, the overall scope of synchronization is directly influenced by:</p>
<ul style="margin-top: 0cm;">
<li class="MsoNormal" style="mso-list: l10 level1 lfo1; tab-stops: list 36.0pt;">The permission profile assigned to the integration account</li>
<li class="MsoNormal" style="mso-list: l10 level1 lfo1; tab-stops: list 36.0pt;">Asset visibility settings within Bynder</li>
<li class="MsoNormal" style="mso-list: l10 level1 lfo1; tab-stops: list 36.0pt;">Metadata visibility rules</li>
<li class="MsoNormal" style="mso-list: l10 level1 lfo1; tab-stops: list 36.0pt;">The account used during connector authorization</li>
</ul>
<p class="MsoNormal">The connector can only synchronize assets that the authenticated account can access.</p>
<p class="MsoNormal">This seemingly simple behavior becomes extremely important when working with large DAM implementations.</p>
<div class="MsoNormal" style="text-align: center;" align="center"><hr /></div>
<h3 class="MsoNormal"><strong>Why Asset Scope Matters</strong></h3>
<p class="MsoNormal">In many organizations, Bynder contains assets for multiple business functions and audiences.</p>
<p class="MsoNormal">Examples include:</p>
<ul style="margin-top: 0cm;">
<li class="MsoNormal" style="mso-list: l3 level1 lfo2; tab-stops: list 36.0pt;">Website assets</li>
<li class="MsoNormal" style="mso-list: l3 level1 lfo2; tab-stops: list 36.0pt;">Campaign assets</li>
<li class="MsoNormal" style="mso-list: l3 level1 lfo2; tab-stops: list 36.0pt;">Product photography</li>
<li class="MsoNormal" style="mso-list: l3 level1 lfo2; tab-stops: list 36.0pt;">Internal communications</li>
<li class="MsoNormal" style="mso-list: l3 level1 lfo2; tab-stops: list 36.0pt;">Regional marketing materials</li>
<li class="MsoNormal" style="mso-list: l3 level1 lfo2; tab-stops: list 36.0pt;">Archived content</li>
<li class="MsoNormal" style="mso-list: l3 level1 lfo2; tab-stops: list 36.0pt;">Partner-specific assets</li>
<li class="MsoNormal" style="mso-list: l3 level1 lfo2; tab-stops: list 36.0pt;">Brand assets</li>
</ul>
<p class="MsoNormal">Not all of these assets are intended for websites powered by Optimizely.</p>
<p class="MsoNormal">Without careful planning, the connector can synchronize substantially more assets than editors actually need.</p>
<p class="MsoNormal">At first glance this may not appear to be a major concern. However, every synchronized asset becomes another content item managed by the Optimizely ecosystem.</p>
<p class="MsoNormal">As synchronization volume grows:</p>
<ul style="margin-top: 0cm;">
<li class="MsoNormal" style="mso-list: l12 level1 lfo3; tab-stops: list 36.0pt;">More items are stored in Optimizely Graph</li>
<li class="MsoNormal" style="mso-list: l12 level1 lfo3; tab-stops: list 36.0pt;">More content records are created</li>
<li class="MsoNormal" style="mso-list: l12 level1 lfo3; tab-stops: list 36.0pt;">More synchronization events are processed</li>
<li class="MsoNormal" style="mso-list: l12 level1 lfo3; tab-stops: list 36.0pt;">Asset selection becomes harder for editors</li>
<li class="MsoNormal" style="mso-list: l12 level1 lfo3; tab-stops: list 36.0pt;">Governance becomes increasingly complex</li>
</ul>
<p class="MsoNormal">Most importantly, organizations should understand how content volume contributes to overall platform usage and operational overhead.</p>
<p class="MsoNormal">For this reason, a successful DAM strategy is not about synchronizing everything that exists inside Bynder.</p>
<p class="MsoNormal">It is about synchronizing only what is required.</p>
<div class="MsoNormal" style="text-align: center;" align="center"><hr /></div>
<h3 class="MsoNormal"><strong>Start With Governance, Not Technology</strong></h3>
<p class="MsoNormal">One of the biggest lessons learned during implementation was that DAM integrations are primarily a governance challenge rather than a technical challenge.</p>
<p class="MsoNormal">The connector itself can be configured very quickly.</p>
<p class="MsoNormal">Determining which assets should be synchronized requires considerably more thought.</p>
<p class="MsoNormal">Before connecting Bynder to Optimizely, I recommend answering questions such as:</p>
<ul style="margin-top: 0cm;">
<li class="MsoNormal" style="mso-list: l14 level1 lfo4; tab-stops: list 36.0pt;">Which assets are intended for public websites?</li>
<li class="MsoNormal" style="mso-list: l14 level1 lfo4; tab-stops: list 36.0pt;">Which business teams own those assets?</li>
<li class="MsoNormal" style="mso-list: l14 level1 lfo4; tab-stops: list 36.0pt;">Which environments require those assets?</li>
<li class="MsoNormal" style="mso-list: l14 level1 lfo4; tab-stops: list 36.0pt;">Who approves synchronization scope changes?</li>
<li class="MsoNormal" style="mso-list: l14 level1 lfo4; tab-stops: list 36.0pt;">How will future asset growth be managed?</li>
</ul>
<p class="MsoNormal">Answering these questions early can prevent a significant amount of cleanup work later.</p>
<div class="MsoNormal" style="text-align: center;" align="center"><hr /></div>
<h3 class="MsoNormal"><strong>The Common Mistake: Connecting With an Administrator Account</strong></h3>
<p class="MsoNormal">The easiest way to enable the connector is often to authenticate using an administrator account.</p>
<p class="MsoNormal">The workflow usually looks something like this:</p>
<ol style="margin-top: 0cm;">
<li class="MsoNormal" style="mso-list: l4 level1 lfo5; tab-stops: list 36.0pt;">Open the Bynder connector.</li>
<li class="MsoNormal" style="mso-list: l4 level1 lfo5; tab-stops: list 36.0pt;">Click Connect.</li>
<li class="MsoNormal" style="mso-list: l4 level1 lfo5; tab-stops: list 36.0pt;">Log in using administrative credentials.</li>
<li class="MsoNormal" style="mso-list: l4 level1 lfo5; tab-stops: list 36.0pt;">Approve access.</li>
<li class="MsoNormal" style="mso-list: l4 level1 lfo5; tab-stops: list 36.0pt;">Start synchronizing.</li>
</ol>
<p class="MsoNormal">The problem is that administrator accounts often see virtually everything.</p>
<p class="MsoNormal">That means the connector can potentially see:</p>
<ul style="margin-top: 0cm;">
<li class="MsoNormal" style="mso-list: l8 level1 lfo6; tab-stops: list 36.0pt;">Website assets</li>
<li class="MsoNormal" style="mso-list: l8 level1 lfo6; tab-stops: list 36.0pt;">Internal assets</li>
<li class="MsoNormal" style="mso-list: l8 level1 lfo6; tab-stops: list 36.0pt;">Historical assets</li>
<li class="MsoNormal" style="mso-list: l8 level1 lfo6; tab-stops: list 36.0pt;">Regional assets</li>
<li class="MsoNormal" style="mso-list: l8 level1 lfo6; tab-stops: list 36.0pt;">Unused assets</li>
<li class="MsoNormal" style="mso-list: l8 level1 lfo6; tab-stops: list 36.0pt;">Archived assets</li>
</ul>
<p class="MsoNormal">In other words, the connector effectively inherits access to the entire DAM repository.</p>
<p class="MsoNormal">This removes any meaningful synchronization boundaries.</p>
<div class="MsoNormal" style="text-align: center;" align="center"><hr /></div>
<h3 class="MsoNormal"><strong>Why Creating a New User Is Not Enough</strong></h3>
<p class="MsoNormal">A common assumption is:</p>
<p class="MsoNormal">"I'll simply create a new user for Optimizely and restrict its permissions."</p>
<p class="MsoNormal">Unfortunately, this is where many implementations run into trouble.</p>
<p class="MsoNormal">Bynder permissions are primarily controlled through Permission Profiles.</p>
<p class="MsoNormal">The effective model looks like this:</p>
<p class="MsoNormal"><strong>Permission Profile → User → Asset Visibility</strong></p>
<p class="MsoNormal">This means that simply creating a new user does not automatically reduce visibility.</p>
<p class="MsoNormal">If the new integration user remains associated with a highly privileged profile, that user may still inherit broad access to assets.</p>
<p class="MsoNormal">In practice, creating a new user and placing it within an administrator-level permission profile often results in another highly privileged user.</p>
<p class="MsoNormal">The desired filtering behavior never materializes.</p>
<p class="MsoNormal">This is why a dedicated Permission Profile becomes essential.</p>
<div class="MsoNormal" style="text-align: center;" align="center"><hr /></div>
<h3 class="MsoNormal"><strong>The Recommended Approach</strong></h3>
<p class="MsoNormal">Instead of creating a user within an existing administrative profile, create:</p>
<ul style="margin-top: 0cm;">
<li class="MsoNormal" style="mso-list: l1 level1 lfo7; tab-stops: list 36.0pt;">A dedicated synchronization user</li>
<li class="MsoNormal" style="mso-list: l1 level1 lfo7; tab-stops: list 36.0pt;">A dedicated synchronization permission profile</li>
<li class="MsoNormal" style="mso-list: l1 level1 lfo7; tab-stops: list 36.0pt;">Dedicated metadata visibility rules</li>
</ul>
<p class="MsoNormal">Together, these become the foundation of your synchronization strategy.</p>
<p class="MsoNormal">The goal is to create an account that acts as a read-only integration consumer and nothing more.</p>
<div class="MsoNormal" style="text-align: center;" align="center"><hr /></div>
<h4><strong>1. Creating a Dedicated Synchronization Profile</strong></h4>
<p class="MsoNormal">The dedicated synchronization profile should be configured with only the permissions required for integration purposes.</p>
<p class="MsoNormal">Recommended permissions include:</p>
<p class="MsoNormal"><strong>Asset Bank</strong></p>
<ul style="margin-top: 0cm;">
<li class="MsoNormal" style="mso-list: l15 level1 lfo8; tab-stops: list 36.0pt;">View assets</li>
<li class="MsoNormal" style="mso-list: l15 level1 lfo8; tab-stops: list 36.0pt;">Search assets</li>
<li class="MsoNormal" style="mso-list: l15 level1 lfo8; tab-stops: list 36.0pt;">View asset details</li>
<li class="MsoNormal" style="mso-list: l15 level1 lfo8; tab-stops: list 36.0pt;">View metaproperties</li>
</ul>
<p class="MsoNormal"><strong>General / Integration</strong></p>
<ul style="margin-top: 0cm;">
<li class="MsoNormal" style="mso-list: l2 level1 lfo9; tab-stops: list 36.0pt;">API Access</li>
<li class="MsoNormal" style="mso-list: l2 level1 lfo9; tab-stops: list 36.0pt;">Manage Webhooks</li>
</ul>
<p class="MsoNormal">Permissions that generally do not need to be enabled include:</p>
<ul style="margin-top: 0cm;">
<li class="MsoNormal" style="mso-list: l7 level1 lfo10; tab-stops: list 36.0pt;">Upload assets</li>
<li class="MsoNormal" style="mso-list: l7 level1 lfo10; tab-stops: list 36.0pt;">Edit assets</li>
<li class="MsoNormal" style="mso-list: l7 level1 lfo10; tab-stops: list 36.0pt;">Delete assets</li>
<li class="MsoNormal" style="mso-list: l7 level1 lfo10; tab-stops: list 36.0pt;">Manage taxonomy</li>
<li class="MsoNormal" style="mso-list: l7 level1 lfo10; tab-stops: list 36.0pt;">Administrative functions</li>
</ul>
<div class="MsoNormal" style="text-align: center;" align="center"><hr /></div>
<div>
<h4><strong>2. Create a Dedicated Synchronization Account</strong></h4>
<p>Once the synchronization profile has been configured, create a dedicated service account and assign it exclusively to that profile.</p>
<p>This account will be used during the Bynder authorization process and will ultimately determine which assets the Optimizely connector can access.</p>
<p>Avoid assigning the account to an existing administrative profile or a profile used by content creators. The goal is to create a narrowly scoped integration account whose sole responsibility is synchronizing approved assets into Optimizely.</p>
<p>By separating the integration account from day-to-day user accounts, you gain:</p>
<ul>
<li>Predictable synchronization behavior</li>
<li>Easier troubleshooting</li>
<li>Clear ownership of integration permissions</li>
<li>Reduced risk of unintentionally exposing additional assets to Optimizely</li>
</ul>
<div class="MsoNormal" style="text-align: center;" align="center"><hr /></div>
</div>
<h4 class="MsoNormal"><strong>3. Using Metadata as a Synchronization Boundary</strong></h4>
<p class="MsoNormal">Many teams think about metadata exclusively in terms of search and categorization.</p>
<p class="MsoNormal">During this implementation, I found it equally useful to think of metadata as a governance mechanism.</p>
<p class="MsoNormal">Metadata can help answer questions such as:</p>
<ul style="margin-top: 0cm;">
<li class="MsoNormal" style="mso-list: l13 level1 lfo11; tab-stops: list 36.0pt;">Should this asset be visible to websites?</li>
<li class="MsoNormal" style="mso-list: l13 level1 lfo11; tab-stops: list 36.0pt;">Which business unit owns this asset?</li>
<li class="MsoNormal" style="mso-list: l13 level1 lfo11; tab-stops: list 36.0pt;">Which region can use this asset?</li>
<li class="MsoNormal" style="mso-list: l13 level1 lfo11; tab-stops: list 36.0pt;">Which environments should receive this asset?</li>
</ul>
<p class="MsoNormal">By implementing metadata-driven visibility, organizations can define synchronization boundaries before assets enter Optimizely.</p>
<p class="MsoNormal">This keeps governance as close as possible to the source system.</p>
<div class="MsoNormal" style="text-align: center;" align="center"><hr /></div>
<h4 class="MsoNormal"><strong>4. Configuring Metadata Visibility</strong></h4>
<p class="MsoNormal">One effective approach is to use a <strong>required metadata property</strong> that identifies whether an asset is intended for website consumption.</p>
<p class="MsoNormal">For example: <strong>VisibleTo</strong><br /><br /><img style="border-width: 1px; border-style: solid;" src="/link/9b93cf8ded06433fb473d4ee88ef7f0d.aspx?1783186950489" width="447" height="174" /></p>
<p class="MsoNormal">To configure this:</p>
<ol style="margin-top: 0cm;">
<li class="MsoNormal" style="mso-list: l17 level1 lfo12; tab-stops: list 36.0pt;">Navigate to <strong>Settings → Taxonomy → Metaproperties Management</strong></li>
<li class="MsoNormal" style="mso-list: l17 level1 lfo12; tab-stops: list 36.0pt;">Select the metadata property</li>
<li class="MsoNormal" style="mso-list: l17 level1 lfo12; tab-stops: list 36.0pt;">Open the <strong>Visibility</strong> configuration</li>
<li class="MsoNormal" style="mso-list: l17 level1 lfo12; tab-stops: list 36.0pt;">Select the synchronization profile</li>
<li class="MsoNormal" style="mso-list: l17 level1 lfo12; tab-stops: list 36.0pt;">Grant/deny visibility only to approved metadata values.</li>
</ol>
<p><img style="border-width: 1px; border-style: solid;" src="/link/f4763bfeca7d40b780f19110f800e0c8.aspx?1783187024542" width="564" height="330" /></p>
<p class="MsoNormal">When configured correctly, the synchronization account becomes effectively blind to assets outside the approved scope.</p>
<div class="MsoNormal" style="text-align: center;" align="center"><hr /></div>
<h4 class="MsoNormal"><strong>5. Validate Before Connecting</strong></h4>
<p class="MsoNormal">One of the most valuable steps in the entire process happens before Optimizely is connected.</p>
<p class="MsoNormal">After creating the synchronization account and permission profile:</p>
<ol style="margin-top: 0cm;">
<li class="MsoNormal" style="mso-list: l11 level1 lfo13; tab-stops: list 36.0pt;">Open an Incognito or InPrivate browser session.</li>
<li class="MsoNormal" style="mso-list: l11 level1 lfo13; tab-stops: list 36.0pt;">Login using the synchronization account.</li>
<li class="MsoNormal" style="mso-list: l11 level1 lfo13; tab-stops: list 36.0pt;">Search for assets.</li>
<li class="MsoNormal" style="mso-list: l11 level1 lfo13; tab-stops: list 36.0pt;">Browse collections.</li>
<li class="MsoNormal" style="mso-list: l11 level1 lfo13; tab-stops: list 36.0pt;">Verify metadata visibility.</li>
<li class="MsoNormal" style="mso-list: l11 level1 lfo13; tab-stops: list 36.0pt;">Validate that only the intended assets are available.</li>
</ol>
<p class="MsoNormal">Ask yourself:</p>
<p class="MsoNormal">If I connect Optimizely using this account right now, am I comfortable synchronizing every asset visible on this screen?</p>
<p class="MsoNormal">If the answer is no, continue refining the profile before proceeding.</p>
<p class="MsoNormal">This simple validation step can save considerable troubleshooting effort later.</p>
<div class="MsoNormal" style="text-align: center;" align="center"><hr /></div>
<h3 class="MsoNormal"><strong>The Authorization Flow Trap</strong></h3>
<p class="MsoNormal">Another lesson learned during implementation is that the authorization process deserves more attention than most teams initially give it.</p>
<p class="MsoNormal">The connector authorization flow uses the account that participates in the OAuth approval process.</p>
<p class="MsoNormal">If an existing browser session already contains administrative Bynder credentials, those credentials may inadvertently be used during authorization.</p>
<p class="MsoNormal">To avoid this:</p>
<ol style="margin-top: 0cm;">
<li class="MsoNormal" style="mso-list: l6 level1 lfo14; tab-stops: list 36.0pt;">Open a fresh InPrivate or Incognito browser window.</li>
<li class="MsoNormal" style="mso-list: l6 level1 lfo14; tab-stops: list 36.0pt;">Login to Optimizely SaaS CMS.</li>
<li class="MsoNormal" style="mso-list: l6 level1 lfo14; tab-stops: list 36.0pt;">Start the Bynder App installation and connection process.</li>
<li class="MsoNormal" style="font-weight: bold;"><strong>Most Important:</strong>
<ol style="margin-top: 0cm;">
<li class="MsoNormal" style="mso-list: l6 level1 lfo14; tab-stops: list 36.0pt;">Installation process must open the Bynder login page.</li>
<li class="MsoNormal" style="mso-list: l6 level1 lfo14; tab-stops: list 36.0pt;">Login using the dedicated synchronization account.</li>
</ol>
</li>
<li class="MsoNormal" style="mso-list: l6 level1 lfo14; tab-stops: list 36.0pt;">Complete the authorization flow.</li>
</ol>
<p class="MsoNormal">Using a clean browser session helps ensure the connector is authorized with the intended account rather than accidentally inheriting access from an existing administrative session.</p>
<div class="MsoNormal" style="text-align: center;" align="center"><hr /></div>
<h4 class="MsoNormal"><strong>Understanding the Synchronization Flow</strong></h4>
<p class="MsoNormal"><strong>Scenario A : Asset is visible to the synchronization account</strong></p>
<ul style="margin-top: 0cm;">
<li class="MsoNormal" style="mso-list: l0 level1 lfo15; tab-stops: list 36.0pt;">Asset uploaded/updated into Bynder.</li>
<li class="MsoNormal" style="mso-list: l0 level1 lfo15; tab-stops: list 36.0pt;">Bynder triggers the OCP connector webhook.</li>
<li class="MsoNormal" style="mso-list: l0 level1 lfo15; tab-stops: list 36.0pt;">Bynder receives a request from the connector.</li>
<li class="MsoNormal" style="mso-list: l0 level1 lfo15; tab-stops: list 36.0pt;">The synchronization account is authorized to view the asset.</li>
<li class="MsoNormal" style="mso-list: l0 level1 lfo15; tab-stops: list 36.0pt;">Bynder returns the asset payload.</li>
<li class="MsoNormal" style="mso-list: l0 level1 lfo15; tab-stops: list 36.0pt;">OCP processes the response.</li>
<li class="MsoNormal" style="mso-list: l0 level1 lfo15; tab-stops: list 36.0pt;">The asset is synchronized into Optimizely Graph.</li>
<li class="MsoNormal" style="mso-list: l0 level1 lfo15; tab-stops: list 36.0pt;">The asset may become available within CMS depending on configuration.</li>
</ul>
<p class="MsoNormal"><img style="border-width: 1px; border-style: solid;" src="/link/a927f1a971c74079be8d3e97e45419be.aspx?1783187744711" width="582" height="391" /></p>
<div class="MsoNormal" style="text-align: center;" align="center"><hr /></div>
<p class="MsoNormal"><strong>Scenario B : Asset is not visible to the synchronization account</strong></p>
<ul style="margin-top: 0cm;">
<li>Asset uploaded/updated into Bynder.</li>
<li class="MsoNormal" style="mso-list: l0 level1 lfo15; tab-stops: list 36.0pt;">Bynder triggers the OCP connector webhook.</li>
<li class="MsoNormal" style="mso-list: l0 level1 lfo15; tab-stops: list 36.0pt;">Bynder receives a request from the connector.</li>
<li class="MsoNormal" style="mso-list: l9 level1 lfo16; tab-stops: list 36.0pt;">Bynder evaluates permissions.</li>
<li class="MsoNormal" style="mso-list: l9 level1 lfo16; tab-stops: list 36.0pt;">Access is denied because the synchronization account cannot see the asset.</li>
<li class="MsoNormal" style="mso-list: l9 level1 lfo16; tab-stops: list 36.0pt;">No asset payload is returned.</li>
<li class="MsoNormal" style="mso-list: l9 level1 lfo16; tab-stops: list 36.0pt;">OCP connector skips synchronization.</li>
</ul>
<p class="MsoNormal">This means filtering occurs naturally through the permission model rather than through custom synchronization logic.</p>
<p class="MsoNormal"><img style="border-width: 1px; border-style: solid;" src="/link/cae36a1cec544c05918e7bcee09a60d8.aspx?1783187879183" width="447" height="428" /></p>
<div class="MsoNormal" style="text-align: center;" align="center"><hr /></div>
<h3 class="MsoNormal"><strong>Key Lessons Learned</strong></h3>
<p class="MsoNormal">One of the biggest realizations are that successful DAM integrations are defined long before the first asset is synchronized.</p>
<p class="MsoNormal">A few recommendations I would strongly encourage:</p>
<ul style="margin-top: 0cm;">
<li class="MsoNormal" style="mso-list: l5 level1 lfo18; tab-stops: list 36.0pt;">Define synchronization boundaries before configuring the connector.</li>
<li class="MsoNormal" style="mso-list: l5 level1 lfo18; tab-stops: list 36.0pt;">Create a dedicated integration profile instead of reusing administrative profiles.</li>
<li class="MsoNormal" style="mso-list: l5 level1 lfo18; tab-stops: list 36.0pt;">Use metadata strategically rather than treating it purely as a categorization tool.</li>
<li class="MsoNormal" style="mso-list: l5 level1 lfo18; tab-stops: list 36.0pt;">Validate permissions using a private browser session before connecting Optimizely.</li>
<li class="MsoNormal" style="mso-list: l5 level1 lfo18; tab-stops: list 36.0pt;">Think carefully about which assets truly belong inside the website ecosystem.</li>
<li class="MsoNormal" style="mso-list: l5 level1 lfo18; tab-stops: list 36.0pt;">Start with a smaller, controlled asset scope and expand incrementally if needed.</li>
</ul>
<p class="MsoNormal">Most importantly:</p>
<p class="MsoNormal"><strong>Just because an asset exists in Bynder does not mean it needs to exist in Optimizely.</strong></p>
<div class="MsoNormal" style="text-align: center;" align="center"><hr /></div>
<h3 class="MsoNormal"><strong>Conclusion</strong></h3>
<p class="MsoNormal">The Bynder connector makes it very easy to bring DAM assets into Optimizely SaaS CMS.</p>
<p class="MsoNormal">However, the long-term success of the integration depends less on connector configuration and more on governance decisions made beforehand.</p>
<p class="MsoNormal">By investing time in permission profiles, metadata design, synchronization boundaries, and dedicated integration accounts, organizations can significantly reduce operational overhead and create a much cleaner experience for both editors and developers.</p>
<div>In my next article, I'll take a deeper look at what happens after synchronization is established. We'll explore how asset visibility changes can create orphan records, how synchronization behavior is impacted when assets move in and out of scope, and the operational challenges that emerge in multi-environment implementations. I'll also discuss environment-specific asset governance considerations, common pitfalls organizations encounter as their DAM footprint grows, and architectural approaches for keeping Optimizely environments clean, scalable, and maintainable over time.<br /><br /></div>
<div>
<div class="MsoNormal" style="text-align: center;" align="center"><hr /></div>
</div>
<div>
<h4 class="_1l4j4na1 _1qskm0h c8urk _1a0p899 _5hqrjx _667h42">📚 Bynder + Optimizely SaaS CMS Integration Series</h4>
<div class="_1l4j4na3 _667h42"><em class="far4bl _667h42">This article is the second installment of a 3-part comprehensive architecture guide:</em></div>
<ul class="_667h42 _1l4j4na6">
<li class="_667h42 _1l4j4na2"><strong class="far4bl _1a0p899 _667h42">✅ Part 1: <a class="_667h42 _1l4j4nac _1c9dtv3 _1by2b93 _1140xq1 _667h42" href="/link/4f215cd334254dfcbc121d5f4e20edd6.aspx">Implementing the Connector — Lessons Learned</a></strong><br /><em class="far4bl _667h42">What metadata syncs, how URLs behave, and how to query/render assets in a Next.js frontend.<br /><br /></em></li>
<li class="_667h42 _1l4j4na2"><strong class="far4bl _1a0p899 _667h42">👉 Part 2: Planning & Filtering — Avoiding Asset Sprawl and Unnecessary Sync</strong> <em class="far4bl _667h42">(You are here)</em><br /><em class="far4bl _667h42">How we achieved metadata-based sync filtering with zero custom code.<br /><br /></em></li>
<li class="_667h42 _1l4j4na2"><strong class="far4bl _1a0p899 _667h42">⏭️ Part 3: <a class="_667h42 _1l4j4nac _1c9dtv3 _1by2b93 _1140xq1 _667h42" href="/link/650c1d72d9a84c28b2355e8942fc7cda.aspx">Exploring Asset Lifecycle Management & Three-Gate Governance</a></strong><br /><em class="far4bl _667h42">Explore a webhook-driven, three-gate model to handle asset updates, environments, and usage verification.</em></li>
</ul>
</div>2026-07-04T18:28:12.0000000ZBlog postImplementing the Bynder DAM Connector with Optimizely SaaS CMS: Lessons Learned<p class="MsoNormal"><em>What I learned while integrating Bynder DAM with Optimizely SaaS CMS, exploring Optimizely Graph, and building a headless frontend experience.</em></p>
<div class="MsoNormal" style="text-align: left;" align="center"><hr />
<h2 class="MsoNormal"><strong>Introduction</strong></h2>
<p class="MsoNormal">While working on an Optimizely SaaS CMS implementation, I spent considerable time understanding how the Bynder DAM connector works, what data gets synchronized, how assets appear in Optimizely Graph, and how frontend applications should consume those assets.</p>
<p class="MsoNormal">Although both Optimizely and Bynder provide documentation, I found very little content that shows the complete end-to-end picture:</p>
<ul style="margin-top: 0cm;">
<li class="MsoNormal" style="mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;">What metadata gets synchronized?</li>
<li class="MsoNormal" style="mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;">How do assets appear in Optimizely CMS?</li>
<li class="MsoNormal" style="mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;">What does the data look like in Optimizely Graph?</li>
<li class="MsoNormal" style="mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;">How do developers render images, videos, and documents?</li>
<li class="MsoNormal" style="mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;">How do public and private assets behave?</li>
<li class="MsoNormal" style="mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;">What are the limitations of the connector?</li>
</ul>
<p><span style="font-size: 12.0pt; line-height: 115%; font-family: 'Aptos',sans-serif; mso-ascii-theme-font: minor-latin; mso-fareast-font-family: Aptos; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin; mso-bidi-font-family: 'Times New Roman'; mso-bidi-theme-font: minor-bidi; mso-ansi-language: EN-IN; mso-fareast-language: EN-US; mso-bidi-language: AR-SA;">This article summarizes my findings and lessons learned from exploring the integration.</span></p>
<div class="MsoNormal" style="text-align: center;" align="center"><hr /></div>
<h3 class="MsoNormal"><strong>What is Optimizely SaaS CMS?</strong></h3>
<p class="MsoNormal">Optimizely SaaS CMS is a cloud-native content management platform that enables organizations to create and manage content experiences across websites, mobile applications, portals, and other digital channels.</p>
<p class="MsoNormal">Key capabilities include:</p>
<ul style="margin-top: 0cm;">
<li class="MsoNormal" style="mso-list: l1 level1 lfo1; tab-stops: list 36.0pt;">Content modeling</li>
<li class="MsoNormal" style="mso-list: l1 level1 lfo1; tab-stops: list 36.0pt;">Headless content delivery</li>
<li class="MsoNormal" style="mso-list: l1 level1 lfo1; tab-stops: list 36.0pt;">Visual editing</li>
<li class="MsoNormal" style="mso-list: l1 level1 lfo1; tab-stops: list 36.0pt;">Multi-site architecture</li>
<li class="MsoNormal" style="mso-list: l1 level1 lfo1; tab-stops: list 36.0pt;">Optimizely Graph integration</li>
<li class="MsoNormal" style="mso-list: l1 level1 lfo1; tab-stops: list 36.0pt;">API-first content management</li>
</ul>
<p class="MsoNormal">Unlike traditional CMS platforms, content in Optimizely SaaS is managed through content types and delivered through APIs and Optimizely Graph.</p>
<div class="MsoNormal" style="text-align: center;" align="center"><hr /></div>
<h3 class="MsoNormal"><strong>What is Bynder?</strong></h3>
<p class="MsoNormal">Bynder is an enterprise Digital Asset Management (DAM) platform.</p>
<p class="MsoNormal">Organizations typically use Bynder to manage:</p>
<ul style="margin-top: 0cm;">
<li class="MsoNormal" style="mso-list: l0 level1 lfo2; tab-stops: list 36.0pt;">Images</li>
<li class="MsoNormal" style="mso-list: l0 level1 lfo2; tab-stops: list 36.0pt;">Videos</li>
<li class="MsoNormal" style="mso-list: l0 level1 lfo2; tab-stops: list 36.0pt;">Brand assets</li>
<li class="MsoNormal" style="mso-list: l0 level1 lfo2; tab-stops: list 36.0pt;">Product photography</li>
<li class="MsoNormal" style="mso-list: l0 level1 lfo2; tab-stops: list 36.0pt;">Brochures and documents</li>
<li class="MsoNormal" style="mso-list: l0 level1 lfo2; tab-stops: list 36.0pt;">Marketing collateral</li>
<li class="MsoNormal" style="mso-list: l0 level1 lfo2; tab-stops: list 36.0pt;">Digital media libraries</li>
</ul>
<p class="MsoNormal">Bynder often serves as the single source of truth for digital assets while Optimizely serves as the source of truth for content.</p>
<div class="MsoNormal" style="text-align: center;" align="center"><hr /></div>
<h3><strong>Why Do We Need a Connector?</strong></h3>
<p class="MsoNormal">Without a connector, editorial teams typically follow this process:</p>
<p class="MsoNormal">Bynder DAM <span style="font-family: Wingdings; mso-ascii-font-family: Aptos; mso-ascii-theme-font: minor-latin; mso-hansi-font-family: Aptos; mso-hansi-theme-font: minor-latin; mso-char-type: symbol; mso-symbol-font-family: Wingdings;"><span style="mso-char-type: symbol; mso-symbol-font-family: Wingdings;">à</span></span> Download Asset <span style="font-family: Wingdings; mso-ascii-font-family: Aptos; mso-ascii-theme-font: minor-latin; mso-hansi-font-family: Aptos; mso-hansi-theme-font: minor-latin; mso-char-type: symbol; mso-symbol-font-family: Wingdings;"><span style="mso-char-type: symbol; mso-symbol-font-family: Wingdings;">à</span></span> Upload Asset to CMS <span style="font-family: Wingdings; mso-ascii-font-family: Aptos; mso-ascii-theme-font: minor-latin; mso-hansi-font-family: Aptos; mso-hansi-theme-font: minor-latin; mso-char-type: symbol; mso-symbol-font-family: Wingdings;"><span style="mso-char-type: symbol; mso-symbol-font-family: Wingdings;">à</span></span> Use Asset on Website<br />OR<br />Bynder DAM <span style="font-family: Wingdings; mso-ascii-font-family: Aptos; mso-ascii-theme-font: minor-latin; mso-hansi-font-family: Aptos; mso-hansi-theme-font: minor-latin; mso-char-type: symbol; mso-symbol-font-family: Wingdings;"><span style="mso-char-type: symbol; mso-symbol-font-family: Wingdings;">à</span></span> Copy Asset URL <span style="font-family: Wingdings; mso-ascii-font-family: Aptos; mso-ascii-theme-font: minor-latin; mso-hansi-font-family: Aptos; mso-hansi-theme-font: minor-latin; mso-char-type: symbol; mso-symbol-font-family: Wingdings;"><span style="mso-char-type: symbol; mso-symbol-font-family: Wingdings;">à</span></span> Paste Asset URL to CMS <span style="font-family: Wingdings; mso-ascii-font-family: Aptos; mso-ascii-theme-font: minor-latin; mso-hansi-font-family: Aptos; mso-hansi-theme-font: minor-latin; mso-char-type: symbol; mso-symbol-font-family: Wingdings;"><span style="mso-char-type: symbol; mso-symbol-font-family: Wingdings;">à</span></span> Use Asset on Website</p>
<p class="MsoNormal">This creates multiple problems:</p>
<ul style="margin-top: 0cm;">
<li class="MsoNormal" style="mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;">Duplicate storage</li>
<li class="MsoNormal" style="mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;">Asset versioning issues</li>
<li class="MsoNormal" style="mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;">Governance challenges</li>
<li class="MsoNormal" style="mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;">Increased maintenance effort</li>
<li class="MsoNormal" style="mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;">Multiple sources of truth</li>
</ul>
<p class="MsoNormal">The Bynder Connector changes the process significantly:</p>
<p class="MsoNormal">Bynder DAM <span style="font-family: Wingdings; mso-ascii-font-family: Aptos; mso-ascii-theme-font: minor-latin; mso-hansi-font-family: Aptos; mso-hansi-theme-font: minor-latin; mso-char-type: symbol; mso-symbol-font-family: Wingdings;"><span style="mso-char-type: symbol; mso-symbol-font-family: Wingdings;">à</span></span> DAM Connector <span style="font-family: Wingdings; mso-ascii-font-family: Aptos; mso-ascii-theme-font: minor-latin; mso-hansi-font-family: Aptos; mso-hansi-theme-font: minor-latin; mso-char-type: symbol; mso-symbol-font-family: Wingdings;"><span style="mso-char-type: symbol; mso-symbol-font-family: Wingdings;">à</span></span> Optimizely Graph & CMS <span style="font-family: Wingdings; mso-ascii-font-family: Aptos; mso-ascii-theme-font: minor-latin; mso-hansi-font-family: Aptos; mso-hansi-theme-font: minor-latin; mso-char-type: symbol; mso-symbol-font-family: Wingdings;"><span style="mso-char-type: symbol; mso-symbol-font-family: Wingdings;">à</span></span> Frontend Application</p>
<p class="MsoNormal">Benefits include:</p>
<ul style="margin-top: 0cm;">
<li class="MsoNormal" style="mso-list: l1 level1 lfo2; tab-stops: list 36.0pt;">Single source of truth</li>
<li class="MsoNormal" style="mso-list: l1 level1 lfo2; tab-stops: list 36.0pt;">No duplicate assets</li>
<li class="MsoNormal" style="mso-list: l1 level1 lfo2; tab-stops: list 36.0pt;">Improved governance</li>
<li class="MsoNormal" style="mso-list: l1 level1 lfo2; tab-stops: list 36.0pt;">Centralized asset management</li>
<li class="MsoNormal" style="mso-list: l1 level1 lfo2; tab-stops: list 36.0pt;">Better scalability</li>
</ul>
<p class="MsoNormal">Editors never need to download and re-upload assets.</p>
<p class="MsoNormal">Instead, references to Bynder assets become available directly within Optimizely CMS.</p>
<div class="MsoNormal" style="text-align: center;" align="center"><hr />
<h2 class="MsoNormal" style="text-align: left;"><strong>Understanding the Bynder Asset Model</strong></h2>
<p class="MsoNormal" style="text-align: left;">One of the first things I wanted to understand was what data becomes available. <span style="font-size: 12.0pt; line-height: 115%; font-family: 'Aptos',sans-serif; mso-ascii-theme-font: minor-latin; mso-fareast-font-family: Aptos; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin; mso-bidi-font-family: 'Times New Roman'; mso-bidi-theme-font: minor-bidi; mso-ansi-language: EN-IN; mso-fareast-language: EN-US; mso-bidi-language: AR-SA;">A Bynder asset can be thought of as a combination of following:</span></p>
<ul class="article-editor-bullet-list">
<li class="article-editor-list-item">
<p class="article-editor-paragraph" style="text-align: left;"><strong>Bynder Managed Fields - </strong>Maintained automatically by Bynder. These fields describe the physical asset itself.</p>
</li>
<li class="article-editor-list-item" style="text-align: left;">
<p class="article-editor-paragraph"><strong>User Managed Fields - </strong>These fields are managed by DAM users and are often used for: Search, Categorization, Filtering, Metadata enrichment.</p>
</li>
<li class="article-editor-list-item" style="text-align: left;">
<p class="article-editor-paragraph"><strong>User Managed Flags: </strong>These fields can influence asset behavior. These become particularly important when assets are exposed to public-facing websites.</p>
</li>
<li class="article-editor-list-item" style="text-align: left;">
<p class="article-editor-paragraph"><strong>URLs:</strong> Assets URLs based on asset object and various configurations and enabled features in Bynder.</p>
</li>
</ul>
<p class="MsoNormal" style="text-align: left;"><span style="font-size: 12.0pt; line-height: 115%; font-family: 'Aptos',sans-serif; mso-ascii-theme-font: minor-latin; mso-fareast-font-family: Aptos; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin; mso-bidi-font-family: 'Times New Roman'; mso-bidi-theme-font: minor-bidi; mso-ansi-language: EN-IN; mso-fareast-language: EN-US; mso-bidi-language: AR-SA;"><br /><img src="/link/717b08ca5a0f40aaa9d6924e17798cc1.aspx" /><br /></span></p>
<div class="MsoNormal" style="text-align: center;" align="center"><hr /></div>
<h3 class="MsoNormal" style="text-align: left;"><strong>Understanding the Available Asset URLs</strong></h3>
<p class="MsoNormal" style="text-align: left;">One of the most useful discoveries was understanding which URLs are available for different asset types. Not every asset type exposes the same URLs.</p>
<div class="MsoNormal" style="text-align: center;" align="center"><hr /></div>
<h4 class="MsoNormal" style="text-align: left;"><strong>Image Assets - </strong>Image assets typically provide:</h4>
<table class="MsoTableGrid" style="border-collapse: collapse; margin-left: 0px; margin-right: auto; width: 79.5455%; height: 233px; border-image: initial; border: medium none currentcolor;">
<tbody>
<tr style="height: 40.7625px;">
<td style="width: 33.7357%; border: 1pt solid windowtext; padding: 0cm 5.4pt; text-align: left; line-height: 1; height: 40.7625px; vertical-align: top;">
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;"><strong>Original URL</strong></p>
</td>
<td style="width: 32.4977%; border-width: 1pt 1pt 1pt medium; border-style: solid solid solid none; border-color: windowtext windowtext windowtext currentcolor; border-image: initial; padding: 0cm 5.4pt; text-align: left; line-height: 1; height: 40.7625px; vertical-align: top;">
<p class="MsoNormal" style="margin-bottom: 0cm; line-height: normal;"><strong>Thumbnail URL</strong></p>
</td>
<td style="width: 33.5809%; border-width: 1pt 1pt 1pt medium; border-style: solid solid solid none; border-color: windowtext windowtext windowtext currentcolor; border-image: initial; padding: 0cm 5.4pt; text-align: left; line-height: 1; height: 40.7625px; vertical-align: top;">
<p class="MsoNormal" style="margin-bottom: 0cm; line-height: normal;"><strong>Transform Base URL</strong></p>
</td>
</tr>
<tr style="height: 65.2px;">
<td style="width: 33.7357%; border-width: medium 1pt 1pt; border-style: none solid solid; border-color: currentcolor windowtext windowtext; border-image: initial; padding: 0cm 5.4pt; text-align: left; line-height: 1; height: 65.2px; vertical-align: top;">
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;">Represents the original uploaded file.</p>
</td>
<td style="width: 32.4977%; border-width: medium 1pt 1pt medium; border-style: none solid solid none; border-color: currentcolor windowtext windowtext currentcolor; padding: 0cm 5.4pt; text-align: left; line-height: 1; height: 65.2px; vertical-align: top;">
<p class="MsoNormal" style="margin-bottom: 0cm; line-height: normal;">Represents a smaller version of the image.</p>
</td>
<td style="width: 33.5809%; border-width: medium 1pt 1pt medium; border-style: none solid solid none; border-color: currentcolor windowtext windowtext currentcolor; padding: 0cm 5.4pt; text-align: left; line-height: 1; height: 65.2px; vertical-align: top;">
<p class="MsoNormal" style="margin-bottom: 0cm; line-height: normal;">Instead of generating multiple physical image versions, Bynder allows images to be transformed dynamically.</p>
</td>
</tr>
<tr style="height: 135.262px;">
<td style="width: 33.7357%; border-width: medium 1pt 1pt; border-style: none solid solid; border-color: currentcolor windowtext windowtext; border-image: initial; padding: 0cm 5.4pt; text-align: left; line-height: 1; height: 135.262px; vertical-align: top;">
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;">Use cases:</p>
<p class="MsoNormal" style="margin-bottom: 0cm; line-height: normal;">High-resolution download, <br />Print-quality rendering, <br />Internal consumption</p>
</td>
<td style="width: 32.4977%; border-width: medium 1pt 1pt medium; border-style: none solid solid none; border-color: currentcolor windowtext windowtext currentcolor; padding: 0cm 5.4pt; text-align: left; line-height: 1; height: 135.262px; vertical-align: top;">
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;">Use cases:</p>
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;">Asset pickers, <br />Search results, <br />Content listings, <br />Media libraries</p>
</td>
<td style="width: 33.5809%; border-width: medium 1pt 1pt medium; border-style: none solid solid none; border-color: currentcolor windowtext windowtext currentcolor; padding: 0cm 5.4pt; text-align: left; line-height: 1; height: 135.262px; vertical-align: top;">
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;">Use cases:</p>
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;">Hero banners, <br />Product images, <br />Responsive image delivery, <br />Mobile optimization, <br />Social sharing images</p>
</td>
</tr>
</tbody>
</table>
<p class="MsoNormal" style="text-align: left;"> Transform Base URL helps improve:</p>
<ul>
<li style="text-align: left;">Performance</li>
<li style="text-align: left;">Page speed</li>
<li style="text-align: left;">Bandwidth consumption</li>
</ul>
<div class="MsoNormal" style="text-align: center;" align="center"><hr /></div>
<h4 class="MsoNormal" style="text-align: left;"><strong>Video Assets - </strong>Video assets typically provide:</h4>
<table class="MsoTableGrid" style="width: 948px; border-collapse: collapse; border-image: initial; height: 188px; border: medium none currentcolor;">
<tbody>
<tr style="mso-yfti-irow: 0; mso-yfti-firstrow: yes;">
<td style="width: 301.017px; border: 1pt solid windowtext; padding: 0cm 5.4pt; text-align: left; vertical-align: top;">
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;"><strong>Original URL</strong></p>
</td>
<td style="width: 300.742px; border-width: 1pt 1pt 1pt medium; border-style: solid solid solid none; border-color: windowtext windowtext windowtext currentcolor; border-image: initial; padding: 0cm 5.4pt; text-align: left; vertical-align: top;">
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;"><strong>Thumbnail URL</strong></p>
</td>
<td style="width: 299.905px; border-width: 1pt 1pt 1pt medium; border-style: solid solid solid none; border-color: windowtext windowtext windowtext currentcolor; border-image: initial; padding: 0cm 5.4pt; text-align: left; vertical-align: top;">
<p class="MsoNormal" style="margin-bottom: 0cm; line-height: normal;"><strong>Video Preview URL</strong></p>
</td>
</tr>
<tr style="mso-yfti-irow: 1;">
<td style="width: 301.017px; border-width: medium 1pt 1pt; border-style: none solid solid; border-color: currentcolor windowtext windowtext; border-image: initial; padding: 0cm 5.4pt; text-align: left; vertical-align: top;">
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;">The complete video asset</p>
</td>
<td style="width: 300.742px; border-width: medium 1pt 1pt medium; border-style: none solid solid none; border-color: currentcolor windowtext windowtext currentcolor; padding: 0cm 5.4pt; text-align: left; vertical-align: top;">
<p class="MsoNormal" style="margin-bottom: 0cm; line-height: normal;">Poster image for the video.</p>
</td>
<td style="width: 299.905px; border-width: medium 1pt 1pt medium; border-style: none solid solid none; border-color: currentcolor windowtext windowtext currentcolor; padding: 0cm 5.4pt; text-align: left; vertical-align: top;">
<p class="MsoNormal" style="margin-bottom: 0cm; line-height: normal;">Optimized preview version.</p>
</td>
</tr>
<tr style="mso-yfti-irow: 2; mso-yfti-lastrow: yes;">
<td style="width: 301.017px; border-width: medium 1pt 1pt; border-style: none solid solid; border-color: currentcolor windowtext windowtext; border-image: initial; padding: 0cm 5.4pt; text-align: left; vertical-align: top;">
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;">Use cases:</p>
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;">Full playback,<br />Downloads,<br />Media processing</p>
</td>
<td style="width: 300.742px; border-width: medium 1pt 1pt medium; border-style: none solid solid none; border-color: currentcolor windowtext windowtext currentcolor; padding: 0cm 5.4pt; text-align: left; vertical-align: top;">
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;">Use cases:</p>
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;">Video cards,<br />Search results,<br />Carousel view</p>
</td>
<td style="width: 299.905px; border-width: medium 1pt 1pt medium; border-style: none solid solid none; border-color: currentcolor windowtext windowtext currentcolor; padding: 0cm 5.4pt; text-align: left; vertical-align: top;">
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;">Use cases:</p>
<p class="MsoNormal" style="margin-bottom: 0cm; line-height: normal;">Video galleries,<br />Content previews,<br />Editorial review</p>
</td>
</tr>
</tbody>
</table>
<div class="MsoNormal" style="text-align: center;" align="center"><hr /></div>
<h4 class="MsoNormal" style="text-align: left;"><strong>Document Assets - </strong>Document assets typically provide:</h4>
<table class="MsoTableGrid" style="width: 584px; border-collapse: collapse; border-image: initial; height: 177px; border: medium none currentcolor;">
<tbody>
<tr style="mso-yfti-irow: 0; mso-yfti-firstrow: yes;">
<td style="width: 276.225px; border: 1pt solid windowtext; padding: 0cm 5.4pt; text-align: left; vertical-align: top;">
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;"><strong>Original URL</strong></p>
</td>
<td style="width: 276.238px; border-width: 1pt 1pt 1pt medium; border-style: solid solid solid none; border-color: windowtext windowtext windowtext currentcolor; border-image: initial; padding: 0cm 5.4pt; text-align: left; vertical-align: top;">
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;"><strong>Thumbnail URL</strong></p>
</td>
</tr>
<tr style="mso-yfti-irow: 1; mso-yfti-lastrow: yes;">
<td style="width: 276.225px; border-width: medium 1pt 1pt; border-style: none solid solid; border-color: currentcolor windowtext windowtext; border-image: initial; padding: 0cm 5.4pt; text-align: left; vertical-align: top;">
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;">Used for:</p>
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;">Document downloads,<br />Direct viewing,<br />PDF rendering</p>
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;"> </p>
</td>
<td style="width: 276.238px; border-width: medium 1pt 1pt medium; border-style: none solid solid none; border-color: currentcolor windowtext windowtext currentcolor; padding: 0cm 5.4pt; text-align: left; vertical-align: top;">
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;">Used for:</p>
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;">Document previews,<br />Search results,<br />Asset browsers</p>
</td>
</tr>
</tbody>
</table>
<div class="MsoNormal" style="text-align: center;" align="center"><hr /></div>
<h2 class="MsoNormal" style="text-align: left;"><strong>Setting Up the Connector</strong></h2>
<p class="MsoNormal" style="text-align: left;">Connector setup is relatively straightforward. Follow the documentation here:<br /><a href="https://support.optimizely.com/hc/en-us/articles/37465644973069-Configure-the-Bynder-app">https://support.optimizely.com/hc/en-us/articles/37465644973069-Configure-the-Bynder-app</a></p>
<p class="MsoNormal" style="text-align: left;">Typical configuration requires:</p>
<ol>
<li style="text-align: left;"><!-- [if !supportLists]-->Bynder Admin Access</li>
<li style="text-align: left;"><!--[endif]-->Webhook permissions on your Bynder user profile to authorize this integration.<br /><span style="mso-no-proof: yes;"><img src="/link/9c05c0fedea141afa9dab9a3c5c06c34.aspx" width="333" height="338" border="0" /><br /><br /></span></li>
<li style="text-align: left;"><span style="mso-no-proof: yes;"><span style="text-indent: -18pt;">Bynder OAuth App, Client ID, Client Secret</span></span></li>
<li style="text-align: left;"><span style="text-indent: -18pt;">OCP (Connect Platform) access in Optimizely SaaS instance.</span></li>
</ol>
<p class="MsoNormal" style="text-align: left;">Note that:<br />a) Setup separate sync for:</p>
<p class="MsoListParagraphCxSpFirst" style="margin-left: 54pt; text-indent: -18pt; text-align: left;"><!-- [if !supportLists]--><span style="mso-bidi-font-family: Aptos; mso-bidi-theme-font: minor-latin;"><span style="mso-list: Ignore;">1.<span style="font: 7.0pt 'Times New Roman';"> </span></span></span><!--[endif]-->Each Bynder object i.e. image, document, video.</p>
<p class="MsoListParagraphCxSpMiddle" style="margin-left: 54pt; text-indent: -18pt; text-align: left;"><!-- [if !supportLists]--><span style="mso-bidi-font-family: Aptos; mso-bidi-theme-font: minor-latin;"><span style="mso-list: Ignore;">2.<span style="font: 7.0pt 'Times New Roman';"> </span></span></span><!--[endif]-->Each Optimizely environment i.e. Dev, Stage, Prod (test1, test2, Production)</p>
<p class="MsoListParagraphCxSpLast" style="margin-left: 54pt; text-indent: -18pt; text-align: left;"><!-- [if !supportLists]--><span style="mso-bidi-font-family: Aptos; mso-bidi-theme-font: minor-latin;"><span style="mso-list: Ignore;">3.<span style="font: 7.0pt 'Times New Roman';"> </span></span></span><!--[endif]-->Each Language (if applicable) otherwise use Neutral language<br /><br /></p>
<p class="MsoNormal" style="text-align: left;">b) <span style="mso-spacerun: yes;"> </span>In the Destination create separate ContentType for each object i.e. Image <span style="font-family: Wingdings; mso-ascii-font-family: Aptos; mso-ascii-theme-font: minor-latin; mso-hansi-font-family: Aptos; mso-hansi-theme-font: minor-latin; mso-char-type: symbol; mso-symbol-font-family: Wingdings;"><span style="mso-char-type: symbol; mso-symbol-font-family: Wingdings;">à</span></span> BynderImage, Document <span style="font-family: Wingdings; mso-ascii-font-family: Aptos; mso-ascii-theme-font: minor-latin; mso-hansi-font-family: Aptos; mso-hansi-theme-font: minor-latin; mso-char-type: symbol; mso-symbol-font-family: Wingdings;"><span style="mso-char-type: symbol; mso-symbol-font-family: Wingdings;">à</span></span> BynderDocument, Video <span style="font-family: Wingdings; mso-ascii-font-family: Aptos; mso-ascii-theme-font: minor-latin; mso-hansi-font-family: Aptos; mso-hansi-theme-font: minor-latin; mso-char-type: symbol; mso-symbol-font-family: Wingdings;"><span style="mso-char-type: symbol; mso-symbol-font-family: Wingdings;">à</span></span> BynderVideo<br /><span style="mso-no-proof: yes;"><!-- [if gte vml 1]><v:shape id="Picture_x0020_1"
o:spid="_x0000_i1027" type="#_x0000_t75" style='width:141.6pt;height:142.8pt;
visibility:visible;mso-wrap-style:square'>
<v:imagedata src="file:///C:/Users/VBanka/AppData/Local/Temp/msohtmlclip1/01/clip_image003.png"
o:title=""/>
</v:shape><![endif]--><!-- [if !vml]--><img src="/link/f5f31192a9884124b0db9dd9fd09fd70.aspx" width="240" height="241" border="0" /><br /><br /><!--[endif]--></span></p>
<p class="MsoNormal" style="text-align: left;">c) Ensure selection of “Make available as CMS Content” checkbox.<br /><span style="mso-no-proof: yes;"><!-- [if gte vml 1]><v:shape id="Picture_x0020_18"
o:spid="_x0000_i1026" type="#_x0000_t75" style='width:277.8pt;height:293.4pt;
visibility:visible;mso-wrap-style:square'>
<v:imagedata src="file:///C:/Users/VBanka/AppData/Local/Temp/msohtmlclip1/01/clip_image005.png"
o:title=""/>
</v:shape><![endif]--><!-- [if !vml]--><img src="/link/282149262aa94df1b3376c4a82e1ac77.aspx" width="370" height="391" border="0" /><br /><br /><!--[endif]--></span></p>
<p class="MsoNormal" style="text-align: left;">Once configured successfully:</p>
<p class="MsoNormal" style="text-align: left;">Bynder Assets <span style="font-family: Wingdings; mso-ascii-font-family: Aptos; mso-ascii-theme-font: minor-latin; mso-hansi-font-family: Aptos; mso-hansi-theme-font: minor-latin; mso-char-type: symbol; mso-symbol-font-family: Wingdings;"><span style="mso-char-type: symbol; mso-symbol-font-family: Wingdings;">à</span></span> DAM Connector <span style="font-family: Wingdings; mso-ascii-font-family: Aptos; mso-ascii-theme-font: minor-latin; mso-hansi-font-family: Aptos; mso-hansi-theme-font: minor-latin; mso-char-type: symbol; mso-symbol-font-family: Wingdings;"><span style="mso-char-type: symbol; mso-symbol-font-family: Wingdings;">à</span></span> Optimizely Graph + CMS Content Type</p>
<p class="MsoNormal" style="text-align: left;">Assets become available inside Optimizely Graph and CMS both without custom code.</p>
<div class="MsoNormal" style="text-align: left;" align="center"><hr /></div>
<h2 class="MsoNormal" style="text-align: left;"><strong>Content Manager Experience</strong></h2>
<p class="MsoNormal" style="text-align: left;">From an editorial perspective, this is where things become interesting.</p>
<p class="MsoNormal" style="text-align: left;">After configuration, editors can browse DAM assets directly inside CMS.</p>
<p class="MsoNormal" style="text-align: left;">The Content Manager navigation typically exposes a dedicated content provider area.</p>
<p class="MsoNormal" style="text-align: left;"><span style="mso-no-proof: yes;"><!-- [if gte vml 1]><v:shapetype
id="_x0000_t75" coordsize="21600,21600" o:spt="75" o:preferrelative="t"
path="m@4@5l@4@11@9@11@9@5xe" filled="f" stroked="f">
<v:stroke joinstyle="miter"/>
<v:formulas>
<v:f eqn="if lineDrawn pixelLineWidth 0"/>
<v:f eqn="sum @0 1 0"/>
<v:f eqn="sum 0 0 @1"/>
<v:f eqn="prod @2 1 2"/>
<v:f eqn="prod @3 21600 pixelWidth"/>
<v:f eqn="prod @3 21600 pixelHeight"/>
<v:f eqn="sum @0 0 1"/>
<v:f eqn="prod @6 1 2"/>
<v:f eqn="prod @7 21600 pixelWidth"/>
<v:f eqn="sum @8 21600 0"/>
<v:f eqn="prod @7 21600 pixelHeight"/>
<v:f eqn="sum @10 21600 0"/>
</v:formulas>
<v:path o:extrusionok="f" gradientshapeok="t" o:connecttype="rect"/>
<o:lock v:ext="edit" aspectratio="t"/>
</v:shapetype><v:shape id="Picture_x0020_20" o:spid="_x0000_i1052" type="#_x0000_t75"
style='width:451.2pt;height:151.8pt;visibility:visible;mso-wrap-style:square'
o:bordertopcolor="yellow pure" o:borderleftcolor="yellow pure"
o:borderbottomcolor="yellow pure" o:borderrightcolor="yellow pure">
<v:imagedata src="file:///C:/Users/VBanka/AppData/Local/Temp/msohtmlclip1/01/clip_image001.png"
o:title=""/>
<w:bordertop type="single" width="6"/>
<w:borderleft type="single" width="6"/>
<w:borderbottom type="single" width="6"/>
<w:borderright type="single" width="6"/>
</v:shape><![endif]--><!-- [if !vml]--><img src="/link/470118ee057e4cdcb0fbfd2a052e02bb.aspx" width="603" height="204" /><!--[endif]--></span></p>
<p class="MsoNormal" style="text-align: left;"><span style="mso-no-proof: yes;"><!-- [if gte vml 1]><v:shape
id="Picture_x0020_1" o:spid="_x0000_i1051" type="#_x0000_t75" style='width:451.2pt;
height:169.8pt;visibility:visible;mso-wrap-style:square' o:bordertopcolor="yellow pure"
o:borderleftcolor="yellow pure" o:borderbottomcolor="yellow pure"
o:borderrightcolor="yellow pure">
<v:imagedata src="file:///C:/Users/VBanka/AppData/Local/Temp/msohtmlclip1/01/clip_image003.png"
o:title=""/>
<w:bordertop type="single" width="6"/>
<w:borderleft type="single" width="6"/>
<w:borderbottom type="single" width="6"/>
<w:borderright type="single" width="6"/>
</v:shape><![endif]--><!-- [if !vml]--><img src="/link/aaa2751bab514ace865a38bbd7c8ab7d.aspx" width="603" height="228" /><!--[endif]--></span></p>
<p class="MsoNormal" style="text-align: left;">At this point, editors do not need to leave CMS to discover assets stored in Bynder.</p>
<p class="MsoNormal" style="text-align: left;">They can: Search, Browse, Filter, Reference assets directly from the content authoring experience.</p>
<div class="MsoNormal" style="text-align: left;" align="center"><hr /></div>
<h2 class="MsoNormal" style="text-align: left;"><strong>How Assets Appear in Optimizely Graph</strong></h2>
<p class="MsoNormal" style="text-align: left;">Once synchronized, DAM assets become queryable through Graph.</p>
<p class="MsoNormal" style="text-align: left;">A simplified query may look like (the exact query will depend on your field mappings)<br style="mso-special-character: line-break;" /><!-- [if !supportLineBreakNewLine]--><br style="mso-special-character: line-break;" /><!--[endif]--></p>
<table class="MsoTableGrid" style="border-collapse: collapse; margin-left: 0px; margin-right: auto; border-image: initial; height: 362px; width: 73.2839%; border: medium none currentcolor;">
<tbody>
<tr style="mso-yfti-irow: 0; mso-yfti-firstrow: yes;">
<td style="width: 0%; border: 1pt solid windowtext; padding: 0cm 5.4pt; text-align: left; vertical-align: top;">
<p class="MsoNormal" style="margin-bottom: 0cm; line-height: normal;"><strong>Image</strong></p>
</td>
<td style="width: 0%; border-width: 1pt 1pt 1pt medium; border-style: solid solid solid none; border-color: windowtext windowtext windowtext currentcolor; border-image: initial; padding: 0cm 5.4pt; text-align: left; vertical-align: top;">
<p class="MsoNormal" style="margin-bottom: 0cm; line-height: normal;"><strong>Video</strong></p>
</td>
<td style="width: 0%; border-width: 1pt 1pt 1pt medium; border-style: solid solid solid none; border-color: windowtext windowtext windowtext currentcolor; border-image: initial; padding: 0cm 5.4pt; text-align: left; vertical-align: top;">
<p class="MsoNormal" style="margin-bottom: 0cm; line-height: normal;"><strong>Document</strong></p>
</td>
</tr>
<tr style="mso-yfti-irow: 1; mso-yfti-lastrow: yes;">
<td style="width: 0%; border-width: medium 1pt 1pt; border-style: none solid solid; border-color: currentcolor windowtext windowtext; border-image: initial; padding: 0cm 5.4pt; text-align: left; vertical-align: top;">
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;">query {</p>
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;"> BynderImage {</p>
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;"> items {</p>
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;"> id</p>
<p class="MsoNormal" style="margin-bottom: 0cm; line-height: normal;"> name</p>
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;"> originalUrl</p>
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;"> thumbnailUrl</p>
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;"> transformBaseUrl</p>
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;"> }</p>
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;"> }</p>
<p class="MsoNormal" style="margin-bottom: 0cm; line-height: normal;">}</p>
</td>
<td style="width: 0%; border-width: medium 1pt 1pt medium; border-style: none solid solid none; border-color: currentcolor windowtext windowtext currentcolor; padding: 0cm 5.4pt; text-align: left; vertical-align: top;">
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;">query {</p>
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;"> BynderVideo {</p>
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;"> items {</p>
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;"> id</p>
<p class="MsoNormal" style="margin-bottom: 0cm; line-height: normal;"> name</p>
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;"> originalUrl</p>
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;"> thumbnailUrl</p>
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;"> videoPreviewURL</p>
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;"> }</p>
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;"> }</p>
<p class="MsoNormal" style="margin-bottom: 0cm; line-height: normal;">}</p>
</td>
<td style="width: 0%; border-width: medium 1pt 1pt medium; border-style: none solid solid none; border-color: currentcolor windowtext windowtext currentcolor; padding: 0cm 5.4pt; text-align: left; vertical-align: top;">
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;">query {</p>
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;"> BynderDocument {</p>
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;"> items {</p>
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;"> id</p>
<p class="MsoNormal" style="margin-bottom: 0cm; line-height: normal;"> name</p>
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;"> originalUrl</p>
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;"> thumbnailUrl</p>
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;"> }</p>
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;"> }</p>
<p class="MsoNormal" style="margin-bottom: 0cm; line-height: normal;">}</p>
</td>
</tr>
</tbody>
</table>
<p class="MsoNormal" style="text-align: left;">One of the biggest advantages is that content and media can now be retrieved through a single API layer.</p>
<div class="MsoNormal" style="text-align: left;" align="center"><hr /></div>
<h2 class="MsoNormal" style="text-align: left;"><strong>Using DAM Assets in Content Types</strong></h2>
<p class="MsoNormal" style="text-align: left;">The connector enables DAM-specific property types.</p>
<p class="MsoNormal" style="text-align: left;">Example:</p>
<table class="MsoTableGrid" style="border-collapse: collapse; border-image: initial; height: 203px; width: 67.718%; border: medium none currentcolor;">
<tbody>
<tr style="mso-yfti-irow: 0; mso-yfti-firstrow: yes; mso-yfti-lastrow: yes;">
<td style="width: 0%; border: 1pt solid windowtext; padding: 0cm 5.4pt; text-align: left; vertical-align: top;">
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;">News Article Page</p>
<p class="MsoListParagraphCxSpFirst" style="mso-add-space: auto; text-indent: -18.0pt; line-height: normal; mso-list: l0 level1 lfo1; margin: 0cm 0cm 0cm 54.0pt;"><!-- [if !supportLists]--><span style="mso-ascii-font-family: Aptos; mso-fareast-font-family: Aptos; mso-hansi-font-family: Aptos; mso-bidi-font-family: Aptos;"><span style="mso-list: Ignore;">-<span style="font: 7.0pt 'Times New Roman';"> </span></span></span><!--[endif]-->Headline</p>
<p class="MsoListParagraphCxSpMiddle" style="mso-add-space: auto; text-indent: -18.0pt; line-height: normal; mso-list: l0 level1 lfo1; margin: 0cm 0cm 0cm 54.0pt;"><!-- [if !supportLists]--><span style="mso-ascii-font-family: Aptos; mso-fareast-font-family: Aptos; mso-hansi-font-family: Aptos; mso-bidi-font-family: Aptos;"><span style="mso-list: Ignore;">-<span style="font: 7.0pt 'Times New Roman';"> </span></span></span><!--[endif]-->Summary</p>
<p class="MsoListParagraphCxSpLast" style="mso-add-space: auto; text-indent: -18.0pt; line-height: normal; mso-list: l0 level1 lfo1; margin: 0cm 0cm 0cm 54.0pt;"><!-- [if !supportLists]--><span style="mso-ascii-font-family: Aptos; mso-fareast-font-family: Aptos; mso-hansi-font-family: Aptos; mso-bidi-font-family: Aptos;"><span style="mso-list: Ignore;">-<span style="font: 7.0pt 'Times New Roman';"> </span></span></span><!--[endif]-->Hero Image</p>
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;">Where:</p>
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;">Hero Image is a Bynder Image reference.</p>
</td>
<td style="width: 0%; border-width: 1pt 1pt 1pt medium; border-style: solid solid solid none; border-color: windowtext windowtext windowtext currentcolor; border-image: initial; padding: 0cm 5.4pt; text-align: left; vertical-align: top;">
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;">Product Page</p>
<p class="MsoListParagraphCxSpFirst" style="mso-add-space: auto; text-indent: -18.0pt; line-height: normal; mso-list: l0 level1 lfo1; margin: 0cm 0cm 0cm 54.0pt;"><!-- [if !supportLists]--><span style="mso-ascii-font-family: Aptos; mso-fareast-font-family: Aptos; mso-hansi-font-family: Aptos; mso-bidi-font-family: Aptos;"><span style="mso-list: Ignore;">-<span style="font: 7.0pt 'Times New Roman';"> </span></span></span><!--[endif]-->Title</p>
<p class="MsoListParagraphCxSpMiddle" style="mso-add-space: auto; text-indent: -18.0pt; line-height: normal; mso-list: l0 level1 lfo1; margin: 0cm 0cm 0cm 54.0pt;"><!-- [if !supportLists]--><span style="mso-ascii-font-family: Aptos; mso-fareast-font-family: Aptos; mso-hansi-font-family: Aptos; mso-bidi-font-family: Aptos;"><span style="mso-list: Ignore;">-<span style="font: 7.0pt 'Times New Roman';"> </span></span></span><!--[endif]-->Product Image</p>
<p class="MsoListParagraphCxSpMiddle" style="mso-add-space: auto; text-indent: -18.0pt; line-height: normal; mso-list: l0 level1 lfo1; margin: 0cm 0cm 0cm 54.0pt;"><!-- [if !supportLists]--><span style="mso-ascii-font-family: Aptos; mso-fareast-font-family: Aptos; mso-hansi-font-family: Aptos; mso-bidi-font-family: Aptos;"><span style="mso-list: Ignore;">-<span style="font: 7.0pt 'Times New Roman';"> </span></span></span><!--[endif]-->Product Video</p>
<p class="MsoListParagraphCxSpLast" style="mso-add-space: auto; text-indent: -18.0pt; line-height: normal; mso-list: l0 level1 lfo1; margin: 0cm 0cm 0cm 54.0pt;"><!-- [if !supportLists]--><span style="mso-ascii-font-family: Aptos; mso-fareast-font-family: Aptos; mso-hansi-font-family: Aptos; mso-bidi-font-family: Aptos;"><span style="mso-list: Ignore;">-<span style="font: 7.0pt 'Times New Roman';"> </span></span></span><!--[endif]-->Product Brochure</p>
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;">Where:</p>
<p class="MsoNormal" style="margin-bottom: 0cm; line-height: normal;">Each asset property can reference a different Bynder asset type i.e. BynderImage, BynderVideo, and BynderDocument</p>
</td>
</tr>
</tbody>
</table>
<div class="MsoNormal" style="text-align: left;" align="center"><hr /></div>
<h3 class="MsoNormal" style="text-align: left;"><strong>Frontend Consumption</strong></h3>
<p class="MsoNormal" style="text-align: left;">Once data is available through Graph, frontend applications can retrieve and render it.</p>
<p class="MsoNormal" style="text-align: left;">Example:</p>
<table class="MsoTableGrid" style="border-collapse: collapse; margin-left: 0px; margin-right: auto; border-image: initial; height: 714px; width: 76.9944%; border: medium none currentcolor;">
<tbody>
<tr style="mso-yfti-irow: 0; mso-yfti-firstrow: yes; mso-yfti-lastrow: yes;">
<td style="width: 0%; border: 1pt solid windowtext; padding: 0cm 5.4pt; vertical-align: top;">
<p class="MsoNormal" style="margin-bottom: 8pt; line-height: 115%; text-align: left;">query {</p>
<p class="MsoNormal" style="margin-bottom: 8pt; line-height: 115%; text-align: left;"> NewsArticle {</p>
<p class="MsoNormal" style="margin-bottom: 8pt; line-height: 115%; text-align: left;"> items {</p>
<p class="MsoNormal" style="margin-bottom: 8pt; line-height: 115%; text-align: left;"> headline</p>
<p class="MsoNormal" style="margin-bottom: 8pt; line-height: 115%; text-align: left;"> heroImage {</p>
<p class="MsoNormal" style="margin-bottom: 8pt; line-height: 115%; text-align: left;"> name</p>
<p class="MsoNormal" style="margin-bottom: 8pt; line-height: 115%; text-align: left;"> thumbnailUrl</p>
<p class="MsoNormal" style="margin-bottom: 8pt; line-height: 115%; text-align: left;"> originalUrl</p>
<p class="MsoNormal" style="margin-bottom: 8pt; line-height: 115%; text-align: left;"> transformBaseUrl</p>
<p class="MsoNormal" style="margin-bottom: 8pt; line-height: 115%; text-align: left;"> }</p>
<p class="MsoNormal" style="margin-bottom: 8pt; line-height: 115%; text-align: left;"> }</p>
<p class="MsoNormal" style="margin-bottom: 8pt; line-height: 115%; text-align: left;"> }</p>
<p class="MsoNormal" style="margin-bottom: 8pt; line-height: 115%; text-align: left;">}</p>
</td>
<td style="width: 0%; border: 1pt solid windowtext; padding: 0cm 5.4pt; vertical-align: top;">
<p class="MsoNormal" style="margin-bottom: 8pt; line-height: 115%; text-align: left;">query {</p>
<p class="MsoNormal" style="margin-bottom: 8pt; line-height: 115%; text-align: left;"> Product {</p>
<p class="MsoNormal" style="margin-bottom: 8pt; line-height: 115%; text-align: left;"> items {</p>
<p class="MsoNormal" style="margin-bottom: 8pt; line-height: 115%; text-align: left;"> title</p>
<p class="MsoNormal" style="margin-bottom: 8pt; line-height: 115%; text-align: left;"> productImage {</p>
<p class="MsoNormal" style="margin-bottom: 8pt; line-height: 115%; text-align: left;"> name</p>
<p class="MsoNormal" style="margin-bottom: 8pt; line-height: 115%; text-align: left;"> thumbnailUrl</p>
<p class="MsoNormal" style="margin-bottom: 8pt; line-height: 115%; text-align: left;"> originalUrl</p>
<p class="MsoNormal" style="margin-bottom: 8pt; line-height: 115%; text-align: left;"> transformBaseUrl</p>
<p class="MsoNormal" style="margin-bottom: 8pt; line-height: 115%; text-align: left;"> }</p>
<p class="MsoNormal" style="margin-bottom: 8pt; line-height: 115%; text-align: left;"> productVideo {</p>
<p class="MsoNormal" style="margin-bottom: 8pt; line-height: 115%; text-align: left;"> name</p>
<p class="MsoNormal" style="margin-bottom: 8pt; line-height: 115%; text-align: left;"> thumbnailUrl</p>
<p class="MsoNormal" style="margin-bottom: 8pt; line-height: 115%; text-align: left;"> originalUrl</p>
<p class="MsoNormal" style="margin-bottom: 8pt; line-height: 115%; text-align: left;"> videoPreviewUrl</p>
<p class="MsoNormal" style="margin-bottom: 8pt; line-height: 115%; text-align: left;"> }</p>
<p class="MsoNormal" style="margin-bottom: 8pt; line-height: 115%; text-align: left;"> productBrochure{</p>
<p class="MsoNormal" style="margin-bottom: 8pt; line-height: 115%; text-align: left;"> name</p>
<p class="MsoNormal" style="margin-bottom: 8pt; line-height: 115%; text-align: left;"> thumbnailUrl</p>
<p class="MsoNormal" style="margin-bottom: 8pt; line-height: 115%; text-align: left;"> originalUrl</p>
<p class="MsoNormal" style="margin-bottom: 8pt; line-height: 115%; text-align: left;"> }</p>
<p class="MsoNormal" style="margin-bottom: 8pt; line-height: 115%; text-align: left;"> }</p>
<p class="MsoNormal" style="margin-bottom: 8pt; line-height: 115%; text-align: left;"> }</p>
<p class="MsoNormal" style="margin-bottom: 8pt; line-height: 115%; text-align: left;">}</p>
</td>
</tr>
</tbody>
</table>
<div class="MsoNormal" style="text-align: left;" align="center"><hr />
<h3><strong>Asset Rendering:</strong></h3>
</div>
<table class="MsoTableGrid" style="border-collapse: collapse; margin-left: 0px; margin-right: auto; width: 75.9895%; border-image: initial; height: 186px; border: medium none currentcolor;">
<tbody>
<tr style="mso-yfti-irow: 0; mso-yfti-firstrow: yes;">
<td style="width: 30.8527%; border: 1pt solid windowtext; padding: 0cm 5.4pt; text-align: left; vertical-align: top;">
<p class="MsoNormal" style="margin-bottom: 0cm; line-height: normal;"><strong>Rendering Images</strong></p>
</td>
<td style="width: 33.8999%; border-width: 1pt 1pt 1pt medium; border-style: solid solid solid none; border-color: windowtext windowtext windowtext currentcolor; border-image: initial; padding: 0cm 5.4pt; text-align: left; vertical-align: top;">
<p class="MsoNormal" style="margin-bottom: 0cm; line-height: normal;"><strong>Rendering Videos</strong></p>
</td>
<td style="width: 35.227%; border-width: 1pt 1pt 1pt medium; border-style: solid solid solid none; border-color: windowtext windowtext windowtext currentcolor; border-image: initial; padding: 0cm 5.4pt; text-align: left; vertical-align: top;">
<p class="MsoNormal" style="margin-bottom: 0cm; line-height: normal;"><strong>Rendering Documents</strong></p>
</td>
</tr>
<tr style="mso-yfti-irow: 1; mso-yfti-lastrow: yes;">
<td style="width: 30.8527%; border-width: medium 1pt 1pt; border-style: none solid solid; border-color: currentcolor windowtext windowtext; border-image: initial; padding: 0cm 5.4pt; text-align: left; vertical-align: top;">
<p class="MsoNormal" style="margin-bottom: 0cm; line-height: normal;"><strong>Basic rendering:</strong><br /><img src="{thumbnailUrl}" /></p>
<div class="MsoNormal" style="margin-bottom: 0cm; text-align: center; line-height: normal;" align="center"><hr /></div>
<p class="MsoNormal" style="margin-bottom: 0cm; line-height: normal;"><br /><strong>Responsive Rendering:</strong><br /><img<br />src="{transformBaseUrl}?width=200" <br />/></p>
</td>
<td style="width: 33.8999%; border-width: medium 1pt 1pt medium; border-style: none solid solid none; border-color: currentcolor windowtext windowtext currentcolor; padding: 0cm 5.4pt; text-align: left; vertical-align: top;">
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;"><strong>Video example:</strong><br /><video controls><br /> <source src="{originalUrl}" /><br /></video></p>
<div class="MsoNormal" style="text-align: center;" align="center"><hr /></div>
<p class="MsoNormal" style="margin-bottom: 0cm; line-height: normal;"><strong>Video Poster:<br /></strong><img src="{thumbnailUrl}" /></p>
</td>
<td style="width: 35.227%; border-width: medium 1pt 1pt medium; border-style: none solid solid none; border-color: currentcolor windowtext windowtext currentcolor; padding: 0cm 5.4pt; text-align: left; vertical-align: top;">
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;"><strong>PDF example:</strong><br /><a href="{originalUrl}"><br /> Download PDF<br /></a></p>
<div class="MsoNormal" style="margin-bottom: 0cm; text-align: center; line-height: normal;" align="center"><hr /></div>
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;"><strong>Preview example:<br /></strong><img src="{thumbnailUrl}" /></p>
</td>
</tr>
</tbody>
</table>
<div class="MsoNormal" style="text-align: left;" align="center"><hr /></div>
<h2 class="MsoNormal" style="text-align: left;">An ideal worflow (Bynder <span style="font-size: 12.0pt; line-height: 115%; font-family: Wingdings; mso-ascii-font-family: Aptos; mso-ascii-theme-font: minor-latin; mso-fareast-font-family: Aptos; mso-fareast-theme-font: minor-latin; mso-hansi-font-family: Aptos; mso-hansi-theme-font: minor-latin; mso-bidi-font-family: 'Times New Roman'; mso-bidi-theme-font: minor-bidi; mso-ansi-language: EN-IN; mso-fareast-language: EN-US; mso-bidi-language: AR-SA; mso-char-type: symbol; mso-symbol-font-family: Wingdings;"><span style="mso-char-type: symbol; mso-symbol-font-family: Wingdings;">à</span></span> Optimizely <span style="font-size: 12.0pt; line-height: 115%; font-family: Wingdings; mso-ascii-font-family: Aptos; mso-ascii-theme-font: minor-latin; mso-fareast-font-family: Aptos; mso-fareast-theme-font: minor-latin; mso-hansi-font-family: Aptos; mso-hansi-theme-font: minor-latin; mso-bidi-font-family: 'Times New Roman'; mso-bidi-theme-font: minor-bidi; mso-ansi-language: EN-IN; mso-fareast-language: EN-US; mso-bidi-language: AR-SA; mso-char-type: symbol; mso-symbol-font-family: Wingdings;"><span style="mso-char-type: symbol; mso-symbol-font-family: Wingdings;">à</span></span> Frontend application):</h2>
<ol>
<li style="text-align: left;">Asset will be uploaded into Bynder along with metadata.</li>
<li style="text-align: left;">Asset will be marked as Public in Bynder (if asset must be available using a public URL).</li>
<li style="text-align: left;">OCP Connector will sync the asset inforamtion into Optimizely Graph.</li>
<li style="text-align: left;">Authors in Optimizely SaaS CMS will be able to ses/select the asset inside the content manager/content items for referencing on relevant fields.</li>
<li style="text-align: left;">Content Items will be published in Optimizely SaaS CMS.</li>
<li style="text-align: left;">Frontend application (nextjs) will retrieve the page item content along with asset URLs using Graph query.</li>
<li style="text-align: left;">Appropriate URL of asset will be used to render/retrieve the asset infroamtion in the application/browser.</li>
<li style="text-align: left;">If frontend application needs asset information that is not synced in Optimizely but available in Bynder then frontend application will use Bynder APIs to retrieve the information.</li>
</ol>
<div class="MsoNormal" style="text-align: left;" align="center"><hr /></div>
<h2 class="MsoNormal" style="text-align: left;"><strong>Public vs Private Assets</strong></h2>
<p class="MsoNormal" style="text-align: left;">One area that deserves special attention is asset visibility.</p>
<table class="MsoTableGrid" style="border-collapse: collapse; width: 67.1769%; height: 327px; border-image: initial; border: medium none currentcolor;">
<tbody>
<tr style="height: 308.862px;">
<td style="width: 50.0644%; border: 1pt solid windowtext; padding: 0cm 5.4pt; text-align: left; vertical-align: top; height: 308.862px;">
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;"><strong>Public Assets</strong></p>
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;">IsPublic = true</p>
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;">Typically means:</p>
<ul>
<li class="MsoNormal" style="line-height: 115%;">Frontend can access asset directly.</li>
<li class="MsoNormal" style="line-height: 115%;">No authentication required.</li>
</ul>
</td>
<td style="width: 50.0644%; border-width: 1pt 1pt 1pt medium; border-style: solid solid solid none; border-color: windowtext windowtext windowtext currentcolor; border-image: initial; padding: 0cm 5.4pt; text-align: left; vertical-align: top; height: 308.862px;">
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;"><strong>Non-Public Assets</strong></p>
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;">IsPublic = false</p>
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;">Potential implications:</p>
<ul>
<li class="MsoNormal" style="line-height: 115%;">Requires authentication</li>
<li class="MsoNormal" style="line-height: 115%;">Requires authorization</li>
<li class="MsoNormal" style="line-height: 115%;">URL will not be accessible publicly</li>
</ul>
<p class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%;">This becomes extremely important for:</p>
<ul>
<li>Extranets</li>
<li>Employee portals</li>
<li class="MsoNormal" style="margin-bottom: 8.0pt; line-height: 115%; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt;">Restricted content</li>
</ul>
<p style="margin-bottom: 8pt; line-height: 115%;">Use <a href="https://bynder-api-documentation.readme.io/reference/get_api-v4-media-id-download">Retrieve asset download</a> location from Bynder API to get the URL to dowlaod the asset item.</p>
</td>
</tr>
</tbody>
</table>
<div class="MsoNormal" style="text-align: left;" align="center"><hr /></div>
<h2 class="MsoNormal" style="text-align: left;"><strong>Things I Learned</strong></h2>
<p class="MsoNormal" style="text-align: left;">After exploring Bynder and the connector, several observations stood out.</p>
<ul>
<li style="text-align: left;"><strong>Not every asset type exposes the same URLs<br /></strong>Images typically expose more transformation capabilities than videos or documents.</li>
</ul>
<div class="MsoNormal" style="text-align: left;" align="center">
<ul>
<li><strong>Transform Base URL is incredibly useful<br /></strong>The Transform Base URL alone can eliminate the need for multiple image renditions.</li>
</ul>
</div>
<div class="MsoNormal" style="text-align: left;" align="center">
<ul>
<li><strong>Public vs Private matters early<br /></strong>Teams should decide asset visibility strategy before building the frontend application.<br />Changing this later can require rework.</li>
</ul>
</div>
<div class="MsoNormal" style="text-align: left;" align="center"><hr /></div>
<h2 class="MsoNormal" style="text-align: left;"><strong>Things to Validate Early</strong></h2>
<ul>
<li class="MsoNormal" style="text-align: left;"><strong>Metadata Availability</strong>
<ul>
<li class="MsoNormal" style="text-align: left;">Not every Bynder field is necessarily synchronized.</li>
<li class="MsoNormal" style="text-align: left;">Always validate:
<ul>
<li class="MsoNormal" style="text-align: left;">Which fields are available?</li>
<li class="MsoNormal" style="text-align: left;">Which fields are searchable?</li>
<li class="MsoNormal" style="text-align: left;">Which fields appear in Graph?<br /><br /></li>
</ul>
</li>
</ul>
</li>
<li class="MsoNormal" style="text-align: left;"><strong>Filtering of Assets</strong>
<ul>
<li class="MsoNormal" style="text-align: left;">You may not need to have all assets in Optimizely. Ideally Assets used on your website or target channel must be synced but rest assets should be avoided.<br />Read the article <a href="/link/30275ac47c4843148eeda8b7d6ed282a.aspx">[Planning Your Bynder DAM and Optimizely SaaS CMS Integration the Right Way: Avoiding Asset Sprawl and Unnecessary Synchronization]</a><br /><br /></li>
</ul>
</li>
<li class="MsoNormal" style="text-align: left;"><strong>Private Asset Consumption</strong>
<ul>
<li class="MsoNormal" style="text-align: left;">Private assets often introduce additional frontend delivery considerations.</li>
<li class="MsoNormal" style="text-align: left;">Validate architecture before implementation.</li>
</ul>
</li>
</ul>
<div class="MsoNormal" style="text-align: left;" align="center">
<ul>
<li><strong>Transformation Support</strong>
<ul>
<li>Image transformations are powerful.</li>
<li>Equivalent functionality may not exist for every asset type. </li>
</ul>
</li>
</ul>
</div>
<div class="MsoNormal" style="text-align: left;" align="center">
<ul>
<li><strong>Connector Scope</strong>
<ul>
<li>The connector solves many DAM scenarios, but not every possible Bynder feature, or workflow may be surfaced through the OOTB connector.<br /><br /></li>
</ul>
</li>
<li><strong>Language Translation</strong>
<ul>
<li>Bynder does not have concept of language version of asset items hence if you need to store language specific content in your assets metadata properties then figure out where that content will be stored and how the translation workflow will be executed. One of the options to keep language specific content inside Bynder is to create language specific properties e.g. Title_en, Title_fr etc. These properties can then be read through the <a href="https://bynder-api-documentation.readme.io/reference/get_api-v4-media-id">Retrieve specific asset</a> endpoint.</li>
<li>Also note that Bynder allows to set the language specific labels for the options inside single select and multi-select properties. But when you retrieve assets information using the API it only returns the default language labels. In case you need language specific labels in your frontend application then you need to get all metadata properties using <a href="https://bynder-api-documentation.readme.io/reference/get_api-v4-metaproperties">Retrieve metaproperties</a> API endpoint.</li>
</ul>
</li>
</ul>
</div>
<div class="MsoNormal" style="text-align: left;" align="center"><hr /></div>
<h2 class="MsoNormal" style="text-align: left;"><strong>Frequently Asked Questions</strong></h2>
<ol>
<li style="text-align: left;"><strong>Does the connector synchronize custom metadata fields?<br /></strong>All text type metadata fields in Bynder are supposed to be exposed through synchronization but actual synchronization depends on the connector configuration. <br />Always validate available fields before finalizing content models.<br /><br /></li>
<li style="text-align: left;"><strong>Can filtering of assets be set during sync configuration?<br /></strong>OOTB connector does not support filtering; it is developed to sync all assets.<br /><span class="far4bl _667h42">The connector itself has no filtering UI, but selective synchronization can be achieved through Bynder's permission profiles and metadata visibility rules — see <a href="/link/30275ac47c4843148eeda8b7d6ed282a.aspx">[Planning Your Bynder DAM and Optimizely SaaS CMS Integration the Right Way: Avoiding Asset Sprawl and Unnecessary Synchronization]</a>.</span><br />Or Using the Bynder API custom connector can be developed to support filtering and other required features based on your business needs. <br /><br /></li>
<li style="text-align: left;"><!-- [if !supportLists]--><strong>Can I call Bynder APIs directly from my frontend application?<br /></strong>Absolutely. A common pattern is: DAM Connector + Bynder APIs. <br />The connector handles asset references while custom APIs handle advanced functionality.<br />Use <a href="https://bynder-api-documentation.readme.io/reference/get_api-v4-media-id">Retrieve specific asset</a> endpoint from Bynder API to retrieve metadata and URLs (including custom metadata) for a specific assets.<br /><br /></li>
<li style="text-align: left;"><!-- [if !supportLists]--><strong>What if information is not synchronized?<br /></strong>Retrieve it directly from Bynder APIs. Examples: Workflow Status, Usage Rights, Approval State, Custom Metadata.<br /><br /></li>
<li style="text-align: left;"><!-- [if !supportLists]--><strong>Can frontend applications retrieve private assets?<br /></strong>It depends on the DAM security model and implementation approach. <br />Possible solutions include: Authentication, Proxy APIs, Token-based access.</li>
</ol>
<div class="MsoNormal" style="text-align: left;" align="center"><hr /></div>
<h2 class="MsoNormal" style="text-align: left;"><strong>Final Thoughts</strong></h2>
<p class="MsoNormal" style="text-align: left;">The Bynder DAM Connector provides a clean bridge between enterprise asset management and modern headless content delivery.</p>
<p class="MsoNormal" style="text-align: left;">The most important takeaway for me was that the connector is not simply an asset picker. It establishes a relationship between:</p>
<p class="MsoNormal" style="text-align: left;">Bynder DAM <span style="font-family: Wingdings; mso-ascii-font-family: Aptos; mso-ascii-theme-font: minor-latin; mso-hansi-font-family: Aptos; mso-hansi-theme-font: minor-latin; mso-char-type: symbol; mso-symbol-font-family: Wingdings;"><span style="mso-char-type: symbol; mso-symbol-font-family: Wingdings;">à</span></span> Optimizely Graph & Optimizely CMS <span style="font-family: Wingdings; mso-ascii-font-family: Aptos; mso-ascii-theme-font: minor-latin; mso-hansi-font-family: Aptos; mso-hansi-theme-font: minor-latin; mso-char-type: symbol; mso-symbol-font-family: Wingdings;"><span style="mso-char-type: symbol; mso-symbol-font-family: Wingdings;">à</span></span> Frontend Applications</p>
<p class="MsoNormal" style="text-align: left;">When implemented correctly, it enables organizations to maintain Bynder as the single source of truth for digital assets while still providing content authors with a seamless CMS authoring experience.</p>
<p class="MsoNormal" style="text-align: left;">For organizations already invested in Bynder and Optimizely SaaS CMS, the connector can significantly simplify asset governance, reduce duplication, and improve overall content delivery architecture.</p>
<div class="MsoNormal" style="text-align: left;" align="center"><hr /></div>
<h4 class="_1l4j4na1 _1qskm0h c8urk _1a0p899 _5hqrjx _667h42" style="text-align: left;">📚 Bynder + Optimizely SaaS CMS Integration Series</h4>
<div class="_1l4j4na3 _667h42" style="text-align: left;"><em class="far4bl _667h42">This article is the first installment of a 3-part comprehensive architecture guide:</em></div>
<ul class="_667h42 _1l4j4na6">
<li class="_667h42 _1l4j4na2" style="text-align: left;"><strong class="far4bl _1a0p899 _667h42">👉 Part 1: Implementing the Connector — Lessons Learned</strong> <em class="far4bl _667h42">(You are here)</em><br /><em class="far4bl _667h42">What metadata syncs, how URLs behave, and how to query/render assets in a Next.js frontend.<br /><br /></em></li>
<li class="_667h42 _1l4j4na2" style="text-align: left;"><strong class="far4bl _1a0p899 _667h42">⏭️ Part 2: <a class="_667h42 _1l4j4nac _1c9dtv3 _1by2b93 _1140xq1 _667h42" href="/link/30275ac47c4843148eeda8b7d6ed282a.aspx">Planning & Filtering — Avoiding Asset Sprawl and Unnecessary Sync</a></strong><br /><em class="far4bl _667h42">Discover how we achieved metadata-based sync filtering with zero custom code.<br /><br /></em></li>
<li class="_667h42 _1l4j4na2" style="text-align: left;"><strong class="far4bl _1a0p899 _667h42">⏭️ Part 3: <a class="_667h42 _1l4j4nac _1c9dtv3 _1by2b93 _1140xq1 _667h42" href="/link/650c1d72d9a84c28b2355e8942fc7cda.aspx">Exploring Asset Lifecycle Management & Three-Gate Governance</a></strong><br /><em class="far4bl _667h42">Explore a webhook-driven, three-gate model to handle asset updates, environments, and usage verification.</em></li>
</ul>
</div>
</div>2026-07-03T12:46:54.0000000ZBlog post