Best practices for creating internal documentation for my org

Get Help
1

The Fibery documentation itself (see image below) is in the Gitbook style that I’d like to use for my company. I want to document all of our internal processes in make scaling, onboarding, and delegation easier, not to mention clarifying business strategy for my own sake. Few questions:

  1. What is the recommended way to:
    1. Make the documentation internal but with the ability to give external access to individual documents? Can I make a top-level document externally exposed such that all sub-documents are also automatically externally exposed?
    2. Assign user permissions to only parts of the documentation.
  2. In the image below, help me to understand the structure of these views. Is this a space with folders (with their icons changed) containing documents? Or are they documents in database that are exposed with Smart Folders, whose icons can be changed, presumably? Just want to check bc I know that Fibery discourages “floating” documents.

If you have any other high-level suggestions about how I should go about this entire documentation process, I’m all ears.

Thanks.

image
image420×672 38 KB

2

You can make a general “Documents” database, or perhaps even a “Wiki” database, and then have a self relation for parent/daughter documents. I believe the Fibery User Guide uses a space to contain the documents, and the space can then be shared publicly. Our team only uses the wiki internally, so we have everything in a folder (with nested smart folders). We have certain fields that make docs (and their subdocuments) appear in the correct nested smart folder). It can be helpful to set up automations that, when a doc has a field changed, the change is also applied to the subdocs.

For giving external access, I’m guessing you mean being able to share a public link with people outside of the workspace. The only way I know to do this is with the “Share” module (top right of the entity view), and I don’t think there’s a way to automatically expose subdocs in this manner. Alternatively, if you are sharing “externally” with just a few people, you could bring them into the workspace as a guest. Then you would be able to set automations to share a doc and its subdocs to these people.