Skip to main content

Scope & Inheritance

A Folder Setting's scope determines which folders it affects. Recursion extends a setting into subfolders, while the setting's nested effect determines what happens when another definition exists lower in the same tree. Together, those choices determine which rule applies to each branch of the folder tree. Limiting a rule to one folder can also stop an inherited rule below it.

These interactions apply to definitions of the same Folder Setting. A File Expiration rule does not replace a webhook or another unrelated setting.

Recursion

Most Folder Settings are recursive by default. Some are always recursive; others offer a choice between This folder only and This folder and all subfolders. Automatically Create New User Folders Here When Users Are Created and Organize Files into Subfolders are never recursive: each acts only where it is configured, so it cannot be inherited or explicitly disabled at a subfolder.

Recursive Folder Settings (Default)

A recursive Folder Setting applies to the folder where it is defined and every descendant folder. Subfolders inherit it without additional configuration. Use a recursive setting when the same rule or control should apply across the entire folder tree.

For example, a recursive setting on /Projects applies to /Projects, /Projects/2026, and /Projects/2026/Q1.

Non-Recursive Folder Settings

A non-recursive Folder Setting applies only where it is defined. A non-recursive setting on /Projects applies to /Projects, but not /Projects/2026 or /Projects/2026/Q1.

Use this scope for a rule needed at one folder level. When the folder already inherits the same setting from above, its Combine or Replace effect also determines whether that ancestor's rule continues into deeper folders.

How Nested Folder Settings Interact

Settings are nested when the same setting is defined at different levels with overlapping scopes. Each setting has a fixed interaction model built into the platform; you cannot choose a different model. For settings that permit nesting, definitions either combine or replace one another.

Combine Effect

For some Folder Settings, multiple definitions are combined where they overlap. The Folder Setting defined on the folder and the Folder Setting defined on the subfolder are both in effect at the subfolder level.

Combine applies when each configuration must continue to take effect, such as notifying multiple destinations or enforcing every folder lock that covers a path. A subfolder definition cannot turn off an inherited Combine setting.

Combine Example

A recursive Send Webhook Folder Setting on /Projects notifies a project tracking application when a file is uploaded. Another Send Webhook setting on /Projects/2026 notifies a finance application when a file is uploaded there.

An upload directly to /Projects sends a webhook to the project tracking application. An upload to /Projects/2026 sends webhooks to both applications because both settings apply there. The subfolder setting adds another notification destination without replacing the setting on /Projects.

Replace Effect

For other Folder Settings, a definition on a subfolder replaces the definition from the folder above it. Only the Folder Setting defined at the subfolder level is in effect within that subfolder's scope.

Replace applies when only one active configuration can apply at a given location and a more specific definition takes precedence. Only Replace settings support explicitly disabling an inherited setting: the subfolder replaces it with no setting.

Replace Example

Assume the File Expiration Folder Setting is configured on the /Projects folder to automatically delete files after 30 days.

Another File Expiration Folder Setting is configured on the /Projects/2026 subfolder to automatically delete files after 7 days.

Because File Expiration is a Folder Setting whose nested effect is Replace, the lower-level configuration takes full effect where their scopes overlap:

  • A file uploaded to /Projects expires after 30 days.
  • A file uploaded to /Projects/2026 expires after 7 days.

The subfolder setting replaces the setting defined higher in the folder hierarchy. The higher-level expiration rule does not apply within the /Projects/2026 subfolder.

Non-Recursive Inheritance Boundaries

Replace Settings

A non-recursive Replace setting applies only at its own folder and also stops the ancestor's definition from applying below that point. Descendants do not fall back to the higher-level rule, even though the local rule does not apply to them. A deeper folder can define its own rule.

For example, recursive File Expiration on /Projects applies to its descendants until a more specific rule intervenes. A non-recursive File Expiration rule on /Projects/2026 applies there, but neither expiration rule applies to /Projects/2026/Q1. Configure an appropriate rule on that branch if it needs expiration.

Combine Settings

A non-recursive Combine setting limits only its own scope. It does not stop higher-level definitions from continuing into descendants.

For example, a recursive webhook on /Projects still applies to /Projects/2026/Q1 when a second, non-recursive webhook is configured on /Projects/2026. At /Projects/2026, both webhooks apply; below it, only the recursive ancestor's webhook applies.

Explicitly Disabling an Inherited Folder Setting

Explicit disabling is available only for Folder Settings whose nested effect is Replace. It replaces an inherited setting with no setting at that folder and throughout its subfolders. This lets a branch of the folder tree opt out of a rule without changing the rule for sibling folders.

For example, if /Projects has recursive File Expiration, explicitly disabling File Expiration at /Projects/Archive stops that inherited expiration rule in /Projects/Archive and its descendants. A deeper subfolder can define its own File Expiration setting. The original /Projects rule does not resume below the disabled folder.

The API option is disable_parent_folder_behavior. Setting it to true is supported only for Replace settings and requires a recursive setting. The API rejects it for every other setting type. The nested-effects table identifies the supported types. Your folder permissions and Root Folder Settings determine whether you can configure a supported exception.

Combine settings remain cumulative: a subfolder cannot disable a setting inherited from a parent. For settings that support non-recursive configuration, limit the setting at the parent where it is configured. For Public Hosting, a permission fence excludes a subfolder and its contents from the parent's Public Hosting URL. Configuring another Public Hosting setting on the subfolder does not remove access through the parent's URL.

Malware Scanning, Remote Server Mount, and Remote Metadata Index cannot be configured below an ancestor with the same setting and cannot be explicitly disabled there. Settings that are never recursive have no inherited setting to disable.

Nested Effects by Folder Setting

The nested effect determines whether a subfolder can replace a setting, add to it, or explicitly disable it. Disabling is a form of replacement, so it is available only for Replace settings.

For settings marked Nesting not allowed, a subfolder cannot define the same setting while it inherits that setting from an ancestor. The inherited setting cannot be explicitly disabled at the subfolder either. Settings marked Never recursive apply only where they are configured, so definitions at different folder levels do not overlap.

Combine describes how permitted definitions interact; individual settings can also restrict which nested configurations are valid. For example, Lock Subfolders does not allow a new lock beneath an existing lock that already covers the entire subtree.