> ## Documentation Index
> Fetch the complete documentation index at: https://docs.delphina.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Data App Folders

> Organize Data Apps in a shared workspace hierarchy and understand who can manage folders

Data App folders organize [Classic Data Apps](/analytics-agent/data-apps) and [Next Gen Data Apps](/analytics-agent/data-apps-next-gen) in one shared hierarchy inside each workspace. Use folders to group apps by team, project, customer, or any other structure that helps people find them.

<Warning>
  A folder changes where a Data App appears, not who can access it. Moving an
  app never changes its owner, editors, publication state, direct URL, or other
  app-level permissions.
</Warning>

## Browse and find Data Apps

The folder tree stays visible while you browse the Data Apps page. Select a folder to see its direct child folders and Data Apps, or select the workspace root (`/`) to return to the top level. Breadcrumbs above the listing show your current location and let you move back through its parent folders.

Within each location:

* Folders appear before Data Apps.
* Existing Data App sorting still controls the order of the apps.
* **My**, **Starred**, **Published**, and **All** filter Data Apps only; the full folder hierarchy remains visible.
* Workspace search looks across every folder and shows the location of each matching Data App. It returns only apps you can already see.

A dimmed folder has no Data App visible to you anywhere in its subtree. It may still contain child folders or Data Apps you cannot access, so dimming does not mean the folder is empty for everyone.

## Organize folders

### Create a folder

Explorers and Developers can create a folder at the workspace root or inside the folder they are viewing. Folder names must be unique among sibling folders, regardless of capitalization.

When you create or clone a Data App while viewing a folder, the new app is placed in that folder. Data Apps created without a folder context are placed at the workspace root.

### Rename, move, or delete a folder

Developers can rename folders, nest them beneath another folder, move them back to the workspace root, and delete them.

Deleting a folder does **not** delete its contents. Its direct child folders and directly assigned Data Apps move to the deleted folder's parent. If that move would create two sibling folders with the same name, Delphina blocks the deletion until you resolve the conflict or choose the offered automatic renaming option.

### Move a Data App

If you have permission to move a Data App, use its **Move** action to choose another folder or the workspace root. In Tree view, you can also drag a Data App leaf onto a folder or `/`. Grid and List rows are not draggable.

Moving either a folder or a Data App preserves stable links and all non-location state.

## Who can manage folders

[Workspace roles](/administration/user-management) determine who can change the shared folder hierarchy.

| Capability                           | Viewer | Explorer | Developer |
| ------------------------------------ | ------ | -------- | --------- |
| Browse the complete folder hierarchy | Yes    | Yes      | Yes       |
| Create a folder                      | No     | Yes      | Yes       |
| Rename a folder                      | No     | No       | Yes       |
| Move or nest a folder                | No     | No       | Yes       |
| Delete a folder                      | No     | No       | Yes       |

Permissions use your role in the workspace containing the folder and its destination. A folder created by an Explorer does not belong to that Explorer: creating it does not grant permission to rename, move, or delete it later.

<Note>
  Folder-management permission does not grant permission to move the Data Apps
  inside a folder. Data App movement follows the separate rules below.
</Note>

## Who can move a Data App

Data App movement depends on app ownership and privacy, not only on workspace role:

* A Data App owner can move their app between folders and the workspace root.
* A workspace Developer can move any non-private Data App in the workspace.
* A private Data App remains owner-only. If its owner has been deactivated, a Developer can use the existing owner-recovery path.
* Being allowed to create or manage folders does not let you move an app you do not otherwise administer.

Moving an app never changes its owner, editors, publication state, versions, stars, URLs, content, or refresh behavior. See [Classic Data App ownership and permissions](/analytics-agent/data-apps#ownership-and-permissions) for app-level access details shared by both Data App versions.

## Visibility does not follow folders

Every member of a workspace can see its complete folder hierarchy and folder names. Each member still sees only the Data Apps allowed by the existing ownership and publication rules.

Folder ancestry never grants access to a Data App and never hides an app you could otherwise access. Search and the listing filters follow the same rule: they can narrow the apps shown to you, but they cannot broaden your access.

<Warning>
  A visible or dimmed folder never reveals the count, identity, or metadata of
  Data Apps you cannot access.
</Warning>

## Related documentation

* [Classic Data Apps](/analytics-agent/data-apps)
* [Next Gen Data Apps](/analytics-agent/data-apps-next-gen)
* [User Management & Roles](/administration/user-management)
