Promoting a MediaFlows Automation from Test to Production

Before you start

You need two Cloudinary product environments — one where the flow was built and tested, one where it will run on real assets — and a flow that has already passed a dry run in the first. If it has not, do that first; testing a media automation before it runs on real assets covers what a passing run looks like. Product environments are separate on the Free plan only in the sense that you get one: two environments start at Plus, three at Advanced (Cloudinary pricing, checked 2026-08-18).

The thing to understand before touching anything: a MediaFlows flow is a graph of blocks whose configuration references values that belong to the environment it was built in — upload preset names, folder paths, structured metadata field IDs, webhook URLs. Copying the flow copies those references verbatim, so the copy points at the test environment’s presets and fields whether or not equivalents exist in production. Promotion is not “copy the flow”; it is “copy the flow, then rebind every one of those references.”

Steps

1. List the bindings before you copy. Open the flow in the MediaFlows builder and walk every block, writing down each environment-specific value it holds: preset names on upload blocks, folder paths on move and filter blocks, metadata field IDs on read and set blocks, notification URLs on webhook blocks, and any value used inside an expression. Do this from the block configuration, not from memory. Discovering a stale binding by watching a production run fail is the expensive way to build this list.

2. Check the production schema against the list. For each metadata field, confirm the field exists in production with the same external ID. External IDs are what block configuration and expressions actually reference; the display label is decoration. A field that exists in production under a different external ID does not error — the read returns nothing, the condition on it evaluates false, and the branch is silently empty. The same applies to presets and folders: same name, same path, or the block has nothing to bind to. Anything missing gets created in production now, matching the test environment exactly.

3. Copy the flow with its trigger disabled. Recreate the flow in the production environment and leave the trigger off. Do not enable it “just to see”. A flow that starts running before its bindings are checked processes real uploads with whatever the copy carried over — test-environment logic, test folder paths, test webhook endpoints — and there is no undo for a moved or overwritten asset.

4. Rebind each value from the list. Go block by block through the list from step 1 and point each reference at the production equivalent. Tick items off; anything left unticked at the end is a branch that will misbehave. Where a webhook URL was a test endpoint, replace it with the production one rather than leaving it to be caught later by an unexpected payload arriving somewhere.

5. Verify the bindings, then enable. Run the flow against a single known asset in production — one you can afford to have processed — and confirm every branch fires: metadata reads return the values you expect, folder moves land where intended, the webhook receives its call. Only when each binding has been exercised do you enable the trigger for real traffic. If a branch comes back empty, the first suspect is an external ID mismatch from step 2, not the block logic.

6. Keep the two schemas identical from here on. Every divergence between the environments — a field renamed in one, a preset added to the other — turns the next promotion from a checklist into a rewrite, because the list from step 1 no longer maps one-to-one. Change schema in test, promote the schema change to production, then promote the flow. If you are promoting often enough that this discipline hurts, that is one of the signals covered in when a media automation should become code, where the schema lives in a repository and is applied to both environments from the same source.

Done looks like

The production flow’s trigger is enabled, every item on the binding list has been rebound and exercised by a real run on a known asset, no branch returned empty, and the production environment’s presets, folders and metadata external IDs match the test environment’s exactly. The next promotion of this flow needs only steps 3 to 5, because the list from step 1 still holds.