Standardise Branding Across Media Without Editing Assets

Before you start

You need three things in place, and the order matters.

A product environment with the assets in it, or at least the upload path that new assets will take. The method below works on assets that already exist and on ones that arrive later, but it only helps with the second group if uploads go through a path you control.

A written brand standard: which mark, which corner, what opacity, what minimum clear space, and what happens on square and portrait crops. If that document does not exist yet, write it before touching any tooling. The single most common failure in this job is not technical; it is that the rule in the flow and the rule in the brand guide say different things a year later, and nobody notices until a customer does.

The brand asset itself uploaded as an asset in the same product environment, because an overlay is referenced by public ID and has to live where the transformation can reach it.

Steps

1. Decide that branding is applied at delivery, not stored in the file.

   Every image-processing tool offers two ways to add a watermark: burn it into the pixels and save the result, or describe it as an operation that runs when the image is served. Take the second one. A watermark baked into the stored asset is irreversible. The original is now unusable for any context that needs it clean: a press kit, a partner co-brand, a print job, a future rebrand. That is the mistake that surfaces a year later, when the logo changes and someone discovers the only copies of 4,000 product shots all carry the old one in the corner. The fix at that point is a re-render of the library from whatever originals still exist, which is a project, not an edit.

   Applied at delivery, the stored file is untouched. The overlay is a URL parameter, computed on request and cached, and the same asset can be served branded, unbranded, or branded differently for a different channel. The transformation reference lists the overlay, gravity, offset and opacity parameters this rests on; every one of them is a delivery-time instruction, none of them modifies the stored asset. If you have a media pipeline that hands finished files to a headless CMS, this is also the point where you stop the CMS from storing its own edited copies.

2. Write the branding once, as a named transformation.

   Do not paste the same chain of overlay parameters into every URL, template and flow. Save it under a name and reference the name. A named transformation is a stored alias for a transformation chain: change the definition, and every URL that references it changes on the next request. That is what turns a rebrand into one edit rather than a re-render. The library does not move; the definition of “branded” moves.

   Name it for what it does, not for what it currently contains: brand-standard, not logo-bottom-right-60pct. The second name is a lie the day the mark moves.

3. Express the rule per aspect ratio, not per asset.

   Overlay placement that works on a landscape crop fails on a square one. A mark sized to sit comfortably in the bottom-right of a 16:9 hero covers a quarter of a 1:1 thumbnail, and on a tall portrait crop it lands on the subject’s face. If the branding standard says “logo, bottom right, 60% opacity” and nothing else, it is under-specified: it silently assumes one aspect ratio.

   Write the rule with a branch per shape. The transformation reference supports conditional transformations keyed on the delivered image’s dimensions and aspect ratio, so one named transformation can carry the landscape rule, the square rule and the portrait rule and pick between them at delivery time. In practice this means three decisions per brand mark: relative size (as a fraction of the shorter side, not a pixel count), position, and the aspect-ratio thresholds where the rule switches. Get these from the brand guide, or add them to it now, because this is exactly the kind of detail a brand guide written for print omits and a media library needs.

   Test the named transformation against one asset of each shape before you go further. Landscape looking right proves nothing about square.

4. Enforce it at upload with a flow, so the assets people add outside the process get caught.

   Applying the transformation at delivery covers every URL you generate. It does not cover assets someone drags into the library from a laptop, uploads through a widget on a form, or drops in via a bulk import, and then links to directly. That is where inconsistency actually enters: not through the pipeline you built, but around it.

   The answer is an automation triggered on upload rather than one triggered by your rendering code. In MediaFlows, a flow that starts on the upload event can tag the new asset, apply an incoming transformation, move it into the folder the delivery templates read from, or reject it if it does not meet a rule, and it runs regardless of who uploaded or how. The flow-building guide covers the upload trigger and the condition and action blocks you chain after it. If your organisation already runs an approval step on incoming assets, the branding check belongs in the same flow, before approval, so a reviewer sees the asset as it will actually be delivered.

   Two cautions. First, “enforce at upload” does not mean “burn in at upload”; step 1 still holds. The upload flow’s job is to make sure the asset ends up where the delivery-time branding applies and carries the metadata that selects the right rule (a channel tag, for instance). Second, MediaFlows’ PowerFlows are prebuilt for common jobs such as moderation, UGC deletion, multilingual alt text and CSV upload; there is not a prebuilt “apply brand standard” flow, so this is one you build from blocks, and it should be short. A branding flow with more than a handful of blocks is usually doing something the named transformation should be doing instead.

5. Put the rule where a designer can see it.

   A branding standard that lives only inside a flow nobody opens will drift from the one in the brand guide. Flows are read by the person who built them and by nobody else; brand guides are read by designers, agencies and new hires. Within a year the two disagree, and the flow is the one that is wrong, because the brand guide is the one people update.

   So the named transformation and the flow are the enforcement, not the specification. Write the rule down in the brand guide (mark, relative size, position, opacity, aspect-ratio breakpoints, and the exact name of the named transformation), and link from the flow’s description back to that section. When the guide changes, the change request is “update brand-standard to match section 4.2”, not a reverse-engineering exercise. If the brand team uses no-code tooling to publish assets to social channels, the same rule name should appear in that publishing flow, so a designer checking one place sees every consumer of the rule.

   The test for whether this step is done: can a designer, with no access to the flow builder, tell you what the branding rule is and whether a given delivered image complies? If not, the rule is still hidden.

What done looks like

Every stored original is unbranded and reusable. Every delivered image carries the brand treatment via one named transformation, and that treatment differs correctly across landscape, square and portrait crops. Assets that enter the library by any route are caught by an upload-triggered flow and land where the delivery-time rule applies. A rebrand is a change to one named transformation and one paragraph of the brand guide, with no re-render of the library. And the rule itself is written in a document designers already read, with the transformation name in it, so the enforcement and the standard cannot silently part ways.