# Access control > The three controls that decide who sees what, how grants combine, and what a restriction does to the files already on someone's disk. Source: https://baalda.com/docs/access Site: Baalda, https://baalda.com Access is per folder and per note, for the whole team or for one person, and it is enforced by the server rather than hidden in the interface. Vault Settings, Members and access carries three controls. Owners and admins see all three, and a plain member sees a read-only roster. ## The three controls - `Everyone in ` (Can edit · Can view · No access): The team's level, applied to every folder and note in the vault. Choosing one rewrites the team's rows across the vault in a single transaction rather than acting as a default that stops at the first folder someone had overridden. People you gave access to by name keep it. - `New members` (Can edit · Can view · No access): What someone sees for the notes that existed before they joined. It is snapshotted when they join, so changing it later does not reach back into people already in the vault. - `Each person` (Can edit everything · Can view everything · No access · Custom): That person's absolute level across the vault. Custom means their per-folder grants differ from any single vault-wide level, and the profile's Access tab is where those are set. ## How a level is decided For one person on one note, in order: 1. A No access row for that person on the note or any folder above it blocks it, unless a deeper row of their own says otherwise. Among one person's own rows, the deepest wins in both directions. 2. A personal level on the vault is absolute for that person. It replaces the team's posture, the owner and admin shortcut and authorship, and only their own folder or note grants lift a No access. 3. Otherwise, owners and admins have edit, and the person who created a note has edit on it. Both shortcuts are skipped when the item is not shared with the team at all, or when the team's level is Can view. 4. Otherwise take the highest of: a grant on the note, a grant on any folder above it, and the vault-wide grant, counting both the team's rows and that person's own. 5. Edit beats view beats nothing. No matching grant means no sync access at all. 6. A lock caps the result at view. It never grants and never removes read. > Folder grants are inherited by everything inside them. A grant on a single note can only raise permission, never lower it. ## Giving one person access The profile's Access tab holds two views of the same thing, remembered per device. - **Board**, the default: three columns, Can edit, Can view and No access, with rows dragged or moved by arrow buttons, a Set everything to menu including Reset to vault default, and Add all or Remove all per column. - **List**: a checkbox tree of folders and notes with an Across the vault level at the top. Both issue the same writes, one resource at a time, and each change applies immediately with a toast naming the result. Levels are colour-coded wherever they appear: Can edit green, Can view amber, No access grey, Custom neutral. ## What asks for confirmation Only changes whose target is No access: the Everyone row, a person's vault-wide level, a row or note in List, the board's Set everything to No access, Remove all, and Reset to vault default. Moving something to Can view or Can edit never asks. ## What a restriction does on disk Losing access moves the local `.md` into that device's trash on every device that had it. A revocation that left a full readable copy behind would be cosmetic, since the file could be opened in any editor forever. The server keeps the content, so this is a de-sync rather than a delete, and restoring access brings the note back: it reappears in the listing, is re-materialized and hydrates on open. > Three rails sit under that. It only runs when the server actually answered about deletions, the file goes to a recoverable trash rather than being destroyed, and any note whose content this device never confirmed upstream is refused outright. ## What a new vault starts as Creating a vault writes an Everyone grant of Can edit alongside its first collection, so an invited teammate lands on a vault with something in it. Vaults created before 2026-08-07 have no such grant and are private until their owner changes the Everyone row. To seal a vault, set Everyone to No access and grant people by name. ## How the server enforces it 1. The desktop app holds a session token from the OS keychain. 2. Before syncing a note it asks the server for a per-document token. 3. The server computes the effective permission and mints a token that is read-write, read-only, or refuses with a 403. 4. The editing socket verifies that token, so a client cannot open a document it was not granted. 5. Tokens are short-lived, ten minutes by default, and revoking access also force-closes live sockets, so the kill is immediate rather than eventual. When the team's level is Can view, or your own personal level is Can view everything, the sidebar padlocks every folder and note rather than only the ones carrying their own lock, because to the person reading it those are the same state.