Short answer
Organize an Obsidian vault with a few shallow top-level folders (Inbox, Projects, Areas, Resources, Archive) and let links and properties do the rest. When a team shares the vault, make the top level who reads it and put topic inside, because the folder is where access is set and every note inside inherits it.
A good Obsidian vault structure is shallow: an inbox, a folder for active work, one for reference, an archive, and links and properties doing the rest. For one person, folders only answer "where did I put it". Once a team shares the vault, the top level also has to answer "who is allowed to read this", and that changes which folders go first.
Most structure advice stops at the first half, because most vaults have one reader. I write the second half from Baalda, where a team edits one vault of plain markdown files together and access is set on folders. That makes the folder tree an access map whether you planned it as one or not, and it gives a simple rule for the top level: who reads it first, topic inside. Below is the solo structure that holds, what each organising tool is actually for, and the shared version.
What is a good Obsidian vault structure?
Five or six top-level folders, no more than two levels deep, and everything else expressed with links and properties:
Vault/
Home.md
Inbox/
Projects/
Q4 pricing review/
Website rewrite/
Areas/
Resources/
Archive/
_templates/
_attachments/Inbox is where anything lands before you decide what it is. Projects holds work with an end date, one folder each. Areas is ongoing responsibilities, Resources is reference material, and Archive is finished work you still want to search. _templates and _attachments keep Obsidian's own plumbing out of the way. Home.md says in a few lines what goes where, so that the rules live in the vault instead of in your head.
That layout is PARA with an inbox in front of it. If you want the method behind it, PARA for teams covers Tiago Forte's rules, and the second brain template is a copy of this folder with the note templates filled in.
The two mistakes that wreck a vault are depth and early filing. A note four folders down is a note you find by search anyway, so the folders cost you a decision every time you file and give nothing back. And a folder per topic made before you have ten notes on that topic is a guess that you then have to maintain.
Folders, links, tags or properties: which one does what?
Each of Obsidian's organising tools answers a different question, and most messy vaults are messy because one tool is doing another's job.
| Tool | Answers | Use it for |
|---|---|---|
| Folders | Where does this note live? | One home per note. On a team, who can read it |
| Links | What is this related to? | Many-to-many connections, maps of content |
| Tags | What loose theme does this touch? | Cross-cutting labels you search across folders |
| Properties | What are this note's facts? | Status, owner, date, type. Queried by Bases |
A note can only sit in one folder, so folders are bad at relationships and good at ownership. Links handle the relationships: a "map of content" note that links twenty notes on one subject does what a subject folder does, without forcing each note to pick one subject.
Properties are the newer piece. Obsidian's help describes them as a way to "organize information about a note", with types for text, lists, numbers, checkboxes and dates. The Bases core plugin builds table views on top of them, and its docs say "All the data in Obsidian Bases is stored in your local Markdown files and their properties." So status: active in a note's properties, plus a Base that filters on it, replaces a whole "Active" folder and never needs a note moved.
If you prefer numbers to names, Johnny.Decimal is the strictest option: no more than ten areas, no more than ten categories in each, and every item gets an ID like 15.22. It suits people who file the same kinds of thing for years. It is more rigid than most vaults need.
What changes when more than one person writes into the vault?
Two people filing into one tree have to agree on what each folder means, which a Home.md mostly solves. The bigger change is that some notes are not meant for everyone, and the structure has to say which.
Obsidian cannot help with that part. Its help page on shared vaults says plainly "Fine-grained permissions are not supported yet", sets a maximum of 20 collaborators per shared vault, and shares the remote vault as a whole. There is no folder that one collaborator can read and another cannot. So in Obsidian the only access boundary is the vault itself, and the honest advice is one vault per audience: a team vault, a leadership vault, a vault per client. That works, but links between vaults do not resolve, search does not cross them, and a note that needs to move to a wider audience has to be copied into another vault. Sharing an Obsidian vault goes through every current method and what each one costs.
Why should a shared vault's top level be who reads it?
Because access in a shared vault flows down the tree. In Baalda, a grant on a folder applies to everything inside it, a grant on a single file can only raise someone's access above what the folder gives them, and the highest grant wins. A person can also be denied outright, and a folder set to Private drops the vault-wide grants, leaving only its creator and the people granted by name. Those rules are short, and they decide the structure for you.
If the top level is topic, Marketing/, Product/, Hiring/, the sensitive notes are scattered: the hiring plan for a marketing role sits under Marketing, the pricing draft sits under Product, and each one needs its own exception. Every exception is a note somebody has to remember to lock, and the one they forget is the one that leaks.
If the top level is audience, you set access once per folder and topic goes inside:
Team vault/
Home.md
Team/ everyone can edit
Projects/
Resources/
Archive/
Leads/ founders and leads only
Hiring/
Finance/
Clients/
Acme/ Acme account team only
Northwind/ Northwind account team only
Handbook/ everyone can view, ops can editInside each audience folder, the solo advice still applies: projects, resources and an archive, shallow, with links and properties doing the cross-referencing. Because it is one vault, links still work across the whole tree, so a project note in Team/ can link to a decision in Leads/, and only the people who can read Leads/ can open it.
This is also what an AI assistant reaches. Each person connects Claude or another assistant to the vault over MCP with their own token, and the tools only list the folders and notes that person can access. An assistant working for someone outside Leads/ cannot read the hiring notes, because the structure says so, not because a prompt asked it nicely. Per-file permissions explains the access model in full.
What happens when a note moves to another folder?
In a shared vault, moving a note changes who can read it. A note dragged from Leads/ into Team/ takes on Team/'s access the moment it lands, which is exactly what you want when a hiring plan becomes an announcement, and exactly what you do not want when it is a slip of the mouse.
Baalda treats a move as an access change and checks it. Through MCP, the move_note tool needs edit access on the note and on the destination folder, so an assistant cannot file something into a folder its person could not write to. The note keeps its id and its full edit history, so links to it and its version history come along. One detail to know: a grant set on the note itself travels with it, and since a file grant can only raise access, a note shared directly with someone stays readable by them after the move.
Obsidian handles the link half of this too. With "Automatically update internal links" turned on, renaming or moving a note rewrites the links that point to it. What it has no equivalent of is the access half, because its folders carry none.
Where does this not help?
For one person, Baalda adds nothing to structure. The solo layout above works in plain Obsidian, and Obsidian's plugin ecosystem, Bases included, is deeper than anything else in this category. If nobody else will ever read the vault, keep it in Obsidian and skip the access rules entirely. The Obsidian comparison is honest about where it wins.
Audience-first structure also does not decide your topics for you. A team still has to agree on what a project is, when it gets archived and who owns the archive, and that agreement belongs in Home.md, not in the software.
And restructuring a shared vault late is an access change on every note you move. Moving Marketing/ into Team/ is one action, but it re-scopes everything inside, so plan the top level before the vault fills up, and check who can see each folder after any large move.