Folder Modes and Integration Access

Folder mode is the access boundary

Folder mode decides whether a no-code integration can see the whole media library or only a selected folder and its subtree. It is therefore an access decision, not merely a choice about how folders appear in a picker. Cloudinary’s folder-mode documentation, updated June 30, 2026, distinguishes the paths used to organize assets from the identifiers used to retrieve them.

The chosen boundary shapes what every user of that integration can reach. If the integration starts at the library root, its users can work across the full library through that connection. If it starts at a scoped folder, assets outside that subtree are not part of the integration’s working area. This distinction matters when media handling sits inside a headless CMS, because the CMS interface may be the only view of the library that editors regularly use.

Scope applies to the integration

The scope belongs to the integration rather than to an individual browsing session. Cloudinary’s guide to integrations with other platforms, updated August 16, 2026, describes integrations that let users select, upload, search, manage, and edit library assets from another platform. Folder scope sets the boundary around those operations for everyone using that configured connection.

A scoped integration is easier to reason about: its visible working set has a named boundary, and content outside that boundary is not accidentally selected through the integration. It is also harder to work around. If someone files a required asset outside the permitted subtree, the integration cannot simply reach across the boundary to retrieve it.

That is the usual trade: a narrower scope limits unintended reach, but it makes correct filing part of the workflow. A whole-library connection tolerates inconsistent filing because users can search more broadly, but every user of the integration can also reach more of the library. The folder boundary should match the team’s actual ownership boundary, not an idealized structure that people will routinely bypass.

Dynamic folders separate identity from location

Dynamic folders decouple an asset’s identifier from its location. Moving an asset between folders, renaming a folder, or moving a folder does not change the asset’s public ID or the delivery URL that refers to it. The folder records where the asset is organized; the public ID remains the delivery identity.

This separation is useful because library organization can change without forcing corresponding URL changes. It also means an integration must not infer an asset’s current folder from the path in its public ID. Cloudinary’s upload documentation, updated June 14, 2026, identifies the public ID as the value used to build transformation and delivery URLs. Treat the location and identifier as separate fields when designing stable asset naming for no-code workflows.

A later mode change is a migration

Changing folder mode after assets have been filed is disruptive because the paths that identify assets change with the mode. Existing imports, stored references, presets, searches, and integration assumptions may all depend on the structure established when those assets entered the library. The work is not finished when a setting changes; the affected paths and references must still be reconciled.

Decide the mode and access boundary before the first bulk import. Once a library has been filed, retrofitting a new structure is a migration rather than a setting change. That migration has to preserve or update the identifiers used by consuming systems while placing assets into the intended folders.

Before starting bulk ingestion from a spreadsheet, record the integration’s root folder, whether descendants are included, the product environment’s folder mode, and the field that downstream systems store as the asset identifier. Those are the details a reader should check next when reviewing an existing integration or approving a new one.