Route assets through approval in a media flow

Prerequisites

Before building the flow, confirm that the media library can store the approval state, reviewer, deadline, approver, and decision time as fields on each asset. Cloudinary describes its field system in the structured metadata documentation, checked 2026-08-18.

You also need a delivery control that can keep an asset unavailable at a public URL until approval. Do not start with notifications or reviewer screens. If a pending asset remains publicly reachable, the approval step records an opinion but does not enforce the decision.

Route each asset through approval

1. Define the approval state machine in metadata

   Approval is a state machine. Represent its current state in structured metadata rather than implying it through the folder containing the asset.

   A workable minimum is pending, approved, and rejected. Add another state only when it changes what the system does. For example, timed_out is useful if an overdue item must leave the active review queue and enter an escalation queue. A generic in_progress state is not useful unless claiming an item prevents another reviewer from acting on it.

   Create fields that let the flow enforce and explain each transition:

   Field	Purpose
   approval_status	Controls whether the asset is pending, approved, rejected, or timed out
   submitted_at	Starts the review deadline
   review_due_at	Determines when escalation must run
   assigned_reviewer	Identifies who currently owns the decision
   approved_by	Records the person responsible for an approval
   approved_at	Records when that approval occurred

   Keep folder placement separate from state. Moving an asset between folders can still help people navigate the library, but the flow must not interpret location as approval. Folder moves are easy to perform manually, and a rename or reorganisation can silently break rules based on paths. A metadata value gives the automation one explicit condition to evaluate.

2. Block delivery before sending the asset to review

   Make the transition into pending perform two operations as one logical submission: apply the pending metadata and ensure the asset cannot be reached through a public URL. The delivery restriction is the enforcement boundary.

   Cloudinary’s moderation PowerFlow documentation, checked 2026-08-18, is the supplied reference for constructing this type of media-review automation. Use the delivery control available in the product environment, but verify its effect instead of treating configuration as proof.

   Test with the exact URL that a publishing system, storefront, or social workflow would use. While approval_status=pending, that request must not return the reviewable asset. Repeat the test for rejected and timed_out. Only approved should be eligible for public delivery.

   This ordering matters. If the notification is sent first, there is a period in which reviewers believe the item is controlled even though delivery is still possible. If restricting delivery fails, submission should fail visibly rather than continuing to the review notification.

3. Build explicit transitions for approve and reject

   Give reviewers two deliberate transitions: pending to approved, and pending to rejected. An approval transition removes the pending restriction only after the state change and decision fields have been written. Rejection keeps the asset unavailable and removes it from the active approval queue.

   Use Cloudinary’s sample PowerFlows, checked 2026-08-18, as implementation references for arranging flow blocks. Treat the samples as starting structures, not as evidence that your own delivery gate, metadata mapping, or timeout path works.

   Prevent transitions that do not make sense. An already approved item should not be approved a second time without first entering a new review cycle. A rejected item should not become public merely because somebody moves it to another folder. If the asset changes after approval, decide whether that edit creates a new submission; if it does, set it back to pending, block delivery again, and clear the earlier decision fields rather than presenting an old approval as current.

   For user-submitted assets, keep this approval routing aligned with the wider process for automating UGC moderation. Automated checks and human approval can be separate transitions, but every route to publication must end in the same enforceable approved state.

4. Make the library view the review queue

   Build a saved or reproducible filtered view whose primary condition is approval_status=pending. Include the asset preview, submission time, due time, and assigned reviewer in the view. Sort by the deadline or submission time so neglected items remain visible.

   Send notifications only as pointers into that queue. Notification without a queue produces an inbox nobody works through: messages are deleted, forwarded, or buried, while nobody can see whether another reviewer completed the task. The reviewable list must be a filtered view of the media library itself because the library holds the current state.

   A reviewer opening an old message should land on the asset’s current record, not a stale snapshot. If the item has already been approved, rejected, or timed out, it should no longer appear in the pending view. That makes the queue self-clearing and prevents two people from deciding the same item based on separate copies of a notification.

5. Add a timeout and an escalation owner

   Timeouts matter more than the approval buttons. The common failure is an asset remaining in review indefinitely because its reviewer left the company.

   Set review_due_at when the asset enters pending. When that time passes, the flow must change something observable: reassign the item, place it in a filtered escalation view, or move it to timed_out. Sending another message while leaving the same absent reviewer and unchanged state is not escalation.

   Give the timeout route an owner who is defined by role or operating responsibility, not solely by the original reviewer’s identity. Keep timed-out assets unavailable at public URLs. A missed deadline is not approval, and it must never become an implicit publish action.

   If the business also removes media after a retention period, keep review deadlines distinct from asset expiry and retention automation. The first determines who must make a decision; the second determines how long the asset should remain. Combining them makes it difficult to tell whether an item disappeared because it was rejected, abandoned, or intentionally expired.

6. Write approval evidence onto the specific asset

   On approval, write approved_by and approved_at to the asset before enabling delivery. Do not rely on a general workflow log as the only record.

   The later question is usually about one item: who approved this image, and when? Asset-level metadata answers that question from the record being investigated. A process-level report may show that the flow ran, but it forces an operator to correlate executions, notifications, and asset identifiers before answering a simple audit question.

   Rejection should receive equivalent item-level evidence if the decision must be reviewed later. At minimum, keep the rejected state and decision time attached to the asset. Add a reason field only if someone will use it to correct, resubmit, or report on rejected work; otherwise it becomes another required input with no operational purpose.

7. Test the failure paths before connecting publishing

   Run one asset through approval, rejection, and timeout. At every non-approved state, request its intended public URL and confirm the asset is unavailable. Confirm that each transition removes the item from the previous filtered view and places it in the correct next view. Then inspect the approved asset directly and verify that its approver and approval time are present.

   Also test a reviewer who can no longer act: assign an item, let its deadline pass, and verify that another owner can find it without searching the departed reviewer’s inbox. This is the test that proves the timeout path is operational rather than decorative.

   If the no-code flow cannot make state changes and delivery controls behave as one dependable transition, move that boundary into code. The decision point is covered in when a media automation should become code. Keep the library metadata as the source of state even if code performs the transition.

Expected result

The finished flow stores approval as asset metadata, keeps every pending, rejected, and timed-out asset unavailable through its public delivery URL, and presents pending work as a filtered library queue. Every submission has a deadline and escalation route. Every approved asset records who approved it and when before public delivery becomes possible.