I’m a little confused on the pros and cons of the different ways to build a company wiki, sop’s, and help articles for our companies. It seems maybe nested docs is the newer/more recommended way to do so now?
In the guide, it’s saying build 2 databases (categories and documents) and then build smart folders in the sidebar to navigate. Fibery
But a lot of articles and even the AI helper suggest using nested docs. When trying them, they seem to make more sense and can create any layout for the info that we want.
What is your latest advice for building these things out? Why would we pick one over the other, etc?
Thanks!
Also, it looks like embedded views in these docs are not showing up for others who are viewing the docs. Is there a better way to create dashboards and help articles if embedded views aren’t sharable? (I tried adding permissions to the original databases and views, but it didn’t change anything on the embedded views inside documents. Is there a reason they aren’t usable for others?)
Hopefully thinking out loud in this forum is helpful 
I just realized you can’t add comments and other useful tools (file uploads, tags etc) to the nested docs (unless I’m missing something).
So does using a rich text field in an entity (database method) give you all of the same benefits of a full document?
There are several things you can do with a database that you can’t do with the documents feature. I myself use just a database for our wiki. Fibery’s user guide is also made via databases. And there have been times in this forum that people from Fibery have said they want to change the documents feature so that it is a database rather than a view.
I’ve only used the documents feature to serve as a simple landing page for a space. For example, we have a Community space that everyone is a member of. There’s a document at the top of this space that describes our workspace and some elements in it as easy reference for people. Literally every other “doc” uses the document database I made.
For us, instead of using two databases, I only used one, with a field used to specify in which smart folders entities should appear.
4 Likes
Interesting! What categories or properties do you usually use to organize with smart folders across the entire organization?
It would be awesome to see some sample, if possible.
Our workspace is not for our whole org, but rather for a branch within the org. It’s possible that our method wouldn’t scale for larger numbers (and more numerous categories/folders). But we have a single-select field named “Parent Folder”. We set this to the desired smart folder. Then for nested entities, we make sure that sub-docs also have this same “Parent Folder” value. The smart folder includes this “Parent Folder” value in its filters. It requires people to properly tag the documents, but we haven’t had an issue so far.
1 Like
Overall, wiki with database is more flexible and powerful, and downsides are very minor. We do want to remove Documents as View completely in the future.
Wiki on Documents
Slightly faster to build a wiki with nested docs maybe.- Document can be linked to any entity (but it also can add confusion, since it disappears from left menu then)
Impossible to manage permissions if you need to give access to some groups of documents for some reason- Can’t have additional fields (comments, state, assigned person, etc)
- Can’t be indexed by AI Search
- Templates workarounds via automations are not possible.
Wiki on Databases
- Documents Database can’t be linked easily to any other database, and if you need that, then too many relations can be confusing
- Can have additional fields (entity comments, state, due date, etc)
- Permissions can be managed per-document or per-group of documents
- Can be part of automations if needed more easily, some templating is possible at least, while with docs templates are impossible
- Can be indexed by AI Search
- Can be visualized via View (like Table view of all documents), etc
2 Likes
