Who Can Edit an Automation, and What That Lets Them Change

What editing rights on an automation actually are

Permission to edit an automation is permission to change what the platform does to every asset that arrives after the edit is saved. It is not a permission over the flow as an object; it is a standing grant over the future contents of the product environment, and the size of that grant is only visible if you read it that way.

The permission is larger than the list makes it look

A permissions table lists “edit flows” as one line among many, next to things like “view analytics” or “manage tags”. Read literally, it sounds like the ability to rearrange blocks on a canvas. What it grants in practice is write access to every asset the flow will ever touch, because a flow runs without a human in the loop each time its trigger fires. Change the block that sets a tag on upload and every upload from that moment carries the new tag; change the condition on a branch and a different population of assets goes down the destructive path.

The MediaFlows user guide describes flows as trigger, condition and action blocks that run when the trigger event occurs. The consequence for access control is that the person editing a flow is not doing one thing to one asset; they are setting a rule that will be applied to an unbounded number of assets, none of which exist yet. A user who has never been given upload or delete rights over a folder can still shape what happens to everything uploaded into it, provided they can edit the flow that watches it. When you review the grant, count it as write access to future assets, not as an editing feature.

If you are still deciding whether the automation belongs on a visual canvas at all, a hosted visual automation against a hand-written webhook handler covers the trade; the access-control point in this section applies either way, but a webhook handler in a repository inherits your code review process, and a canvas does not unless you build one.

Overwrite is present even without a delete block

A flow that writes metadata can also overwrite it. There is no separate “overwrite” capability to grant or withhold: a block that sets a structured metadata field, a tag or a context value writes whatever it is configured to write, and if a value was already there, the previous value is replaced. Whether the write is an enrichment or a loss depends entirely on what was there before, and the canvas does not know.

This matters because a review that scans a flow for destructive blocks — delete asset, remove tag, move to trash — and finds none will conclude the flow is safe. It is not. A metadata-enrichment flow of the kind described in enriching asset metadata automatically at upload can clobber a caption a human wrote, a rights field a legal team filled in, or an approval status another flow set. The capability to destroy information is inherent in the capability to write it, so the destructive surface of a flow is the set of fields it writes, not the set of blocks with alarming names.

When the same fields are written from more than one place — an upload flow and an approval routing flow both touching a status field, for instance — the question of who can edit either flow becomes the question of who can silently change what the other one sees.

Roles start above the free tier

Role-based administration is a paid-tier feature. On the Cloudinary pricing page as checked on 2026-08-18, the Free plan of the Image & Video API includes 3 users and 1 product environment; the separation of users into roles with different capabilities is not part of that tier. The practical result is that on a free plan every user with access has the same access. There is no viewer who cannot edit and no editor who cannot administer, because there is no distinction to draw.

For a team of three that is often fine, and the fact that it is often fine is what makes it easy to forget when the team grows. Access does not get narrower on its own when a plan is upgraded; the roles become available and someone has to assign them.

On the DAM side, Cloudinary’s roles and permissions documentation sets out the role model for Assets, which is a separately purchased product from the Image & Video API. A paid API plan does not raise DAM limits beyond Assets Free, and Assets Enterprise does not raise API limits, so the roles available in one product do not tell you what is available in the other. If you rely on the DAM role model to constrain who can edit an automation, confirm that the role actually governs the automation surface and not only the media library.

Why the tension resolves in the wrong direction

The people who most need to edit flows are usually the ones without platform administration rights. That is not an accident of any one organisation; it follows from what flows are for. A marketing operations lead wants to change the tag applied to campaign uploads. A content editor wants to add a step to an approval route. A localisation manager wants alt text generated in a fourth language. None of these people administer the platform, and none of them should need to.

The path of least resistance, when one of them asks to change a flow and cannot, is to grant them the administrator role. It unblocks them in a minute. It also hands them user management, environment configuration and every other administrative capability, none of which they asked for and none of which anyone will remember to take back. This is the mechanism by which least-privilege dies in practice: not through a decision to abandon it, but through a sequence of individually reasonable unblockings.

The alternative is to treat flow editing as its own grant and to hold the line that it does not require administration. Where the plan tier supports roles, that means finding or defining a role that covers flow editing without the rest. Where it does not — on a free plan — it means accepting that everyone with access can edit everything, and sizing the user list accordingly rather than pretending the constraint exists.

Review edit rights on the publishing cadence

Most teams already review who can publish. Publishing puts something in front of an audience, the consequences of a bad publish are visible, and so the list of publishers gets looked at. Reviewing who can edit an automation is worth doing on the same cadence, because the consequences are comparable: an edited flow changes what happens to every asset from that point on, and unlike a bad publish, the change is not visible in any one asset. It is visible only in aggregate, and often only after enough assets have gone through that reversing it is a project.

A review of edit rights asks three things. Who currently holds the right, and is each of them someone whose job involves changing flows now, rather than someone who needed it once. Which flows write which fields, so that the overwrite surface is known rather than assumed. And whether any of the holders were granted administrator rights as a shortcut and can be moved to a narrower role. If the answer to the first question is “everyone, because we are on the free plan”, the review is still worth doing; it just becomes a review of the user list.

Version control for automations built on a visual canvas is the complementary control: knowing who can edit tells you who could have made a change, and a version history tells you who did.

What to check next

The current role model for the DAM is in the roles and permissions documentation, and the plan features that gate roles are on the pricing page; both change, and the figures above were checked on 2026-08-18. The MediaFlows user guide describes what a flow can do to an asset, which is the list you need when working out what a given editor could change. If you are building your first flow, building a first media automation flow from blocks covers the canvas itself; decide who will be allowed to edit it before it goes live, because that decision is harder to revisit once the flow is load-bearing.