How do you organize product documentation and SOPs in Obsidian?

rixcyshah · July 29, 2026, 9:38am

I’ve been using Obsidian to organize documentation for a software product, and it’s becoming one of my favorite tools for keeping everything connected.

Right now, my vault includes feature documentation, API notes, release history, meeting notes, customer feedback, integration guides, and standard operating procedures (SOPs). Internal links and backlinks have made it much easier to find related information compared to traditional folders.

One challenge I’m still working on is keeping documentation organized as the product grows. For example, we’re maintaining documentation for MembershipAnywhere, a digital membership platform, and there are a lot of interconnected topics digital membership card , CRM integrations, onboarding guides, support articles, release notes, and feature requests. It’s easy for information to become scattered over time.

I’m curious how others structure larger knowledge bases in Obsidian.

Do you rely mostly on folders, tags, or links?
Do you create separate vaults for products and internal documentation?
Which plugins have made the biggest difference for managing technical documentation?
How do you prevent duplicate notes as your documentation grows?

I’d love to see examples of workflows or vault structures that have worked well for software teams or product documentation.

dawni · August 1, 2026, 6:22am

Do you rely mostly on folders, tags, or links?

Links in properties

Do you create separate vaults for products and internal documentation?

No, one vault to rule them all

Which plugins have made the biggest difference for managing technical documentation?

Bases (core) for navigating, along with meaningful file names and links in properties
Note Composer (core) for organizing and expanding
Templater for quick consistency
- rare but useful: an external editor’s regex-replace or Linter for clean-up or mind-change
Local Backup as part of a full backup scheme for peace of mind and (rare but useful) reversion

How do you prevent duplicate notes as your documentation grows?

In small part: folders and succinct, descriptive file names—I can’t accidentally start a new “SOP responsibilities” note in a folder where I’ve already started an “SOP responsibilities” note.
In large part: links in properties and Bases

I’d love to see examples of workflows or vault structures that have worked well for software teams or product documentation.

Expand for simplified documentation example with links in properties

In this set-up, file names and folders don’t matter for organization. File names matter primarily for linking in the note body (finding them in the link suggester) and for directly opening notes (finding them in the quick switcher). This example uses basic file names, but do as you please.

Platform A scope.md

---
recordOf:
  - "[[scopes]]"
  - "[[Platform A SOP]]"
title: scope
position: 3
---

Platform A SOP.md

---
recordOf:
  - "[[SOPs]]"
  - "[[Platform A]]"
title: SOP
---

Platform A.md

---
recordOf:
  - "[[external tools]]"
  - "[[Project A]]"
---

Project A.md

---
recordOf:
  - "[[projects]]"
  - "[[Client A]]"
---

Client A.md

---
recordOf:
  - "[[clients]]"
---

Team A.md

---
recordOf:
  - "[[teams]]"
  - "[[Client A]]"
  - "[[Client F]]"
---

Dwight S.md

---
recordOf:
  - "[[people]]"
  - "[[Team A]]"
  - "[[Team D]]"
  - "[[Team K]]"
title: Dwight Schrute
---

With as little as one list property whose values link to containing notes, a base can show all the relationships I’m interested in, including each note’s lineage up and down the chain of “records”:

client A > project A > tool A > SOP > scope

… peer records:

SOP > [ title_page, purpose, scope, ... ]

… and combinations thereof, such as for histories:

SOP > title_page > revisions > [ draft 1, draft 2, draft 3 ]
    >    purpose > revisions > [ draft 1                   ]
    >      scope > revisions > [ draft 1, draft 2          ]

Displaying overviews like “every record and sub-record of client A” becomes trivial, while groups and filters (or even just search) reveal more helpful things like “documentation for all external tools shared among client A and client B’s projects”. Or “SOP cautions for tools across all clients for which person A is a team member”. Or “did I already start writing the SOP purpose for platform A?”

This also lets you open (or create from a ghost link) any categorical record (e.g., “external tools”, “teams”, “projects”, “SOPs”) such that a side base immediately displays records of that record (all external tools, all teams, all projects, all SOPs) and holders of that record (every project with an external tool, every client assigned a team, every SOP with—or yet without—a checklist, etc.).

Add summaries and other metadata to Properties (dates, reminders, statuses), and Bob’s your documentation’s uncle.

Screenshots of one base applied to various notes (records)…

table:

grouped cards:

grouped table:

grouped list:

a record with a lot going on: